I'm guessing you are already aware of this though 😉
Conversation
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…
3
1
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
Wait, wat.
1
2
Yep, Rust didn't have env capture at first (nor overloading, nor _shadowing_)
Ambiguity is my least-favourite thing in PL. Even minor bits.
1
6
You mean env capture for closures? Did you have something like C++'s explicit captures? Or did you have to pass by param?
Yes, no closures. We had local functions and a 'bind' operator to bind 0-or-more actuals (or wildcards) into a function, creating a new one.
1
1
It's a copy of a feature I quite like in Sather. It's very obvious what's going on, buys you currying and closures w/ very low ambiguity.
2
1
Show replies