overloading is overrated, laws aren't twitter.com/mxavier/status
This Tweet is unavailable.
3
14
Conversation
By the way is there any reason you couldn't attach laws to just like, a record of functions? Why are classes special?
4
4
You're on to something very fundamental about type classes ;-)
1
1
What is it?
(Not sure if I should be thinking in the direction of "they're actually not special" or "they're more special than I think!")
2
1
Type classes are just a fancy, built-in way of passing records of functions around implicitly. Alas, they live in a separate language space.
1
2
I'm guessing you are already aware of this though 😉
1
2
1
3
I mean nothing too profound -- type classes tie "laws" to type-directed implicit arguments in a way that mystifies the two distinct concepts
2
4
in ML signatures specify an interface -- over both types and values -- and you can associate laws with the signature. much neater imo!
2
1
11
Tbh part of me regrets not having a sufficiently-strong set of counterarguments ready at the time, against the push for traits in Rust.
2
5
Tbh I do prefer the 'programming with interface constraints' feeling I get using TCs. I would prefer traditional TCs over ML modules…
For something like Eq, I really want implicit module passing. Damnnit if I'm gonna pass around/instantiate that module manually.
1
yup punting for so long on solving this problem properly (see also Standard ML's "eqtype" nonsense) is a big failing of the ML community
1
1
Show replies
Interesting. I really prefer the "module as set of operations & laws over types" stance when working. Don't mind naming instances at all.
1
1
But again, I'm the guy who thinks environment capture is too much magic to include as a feature :P
1
4
Show replies
My feeling is that (pardon the cliché) typeclasses are the worst of all module systems, except for all the others.
1
5
Yeah I know. And in the grand scheme of things any response to Rust’s incredible success is a bit churlish of me. I just daydream sometimes.
2
4
Show replies