Boston Haskell
2 HN recommenders · recommended in 5 months, 2015–2024
1:42:53 · 36K views · Feb 16, 2015
Edward Kmett speaks at the Boston Haskell meetup about type classes and the design tradeoffs of global coherence compared with other approaches to implicit instances. It covers why uniqueness of instances matters for reasoning and refactoring.
HN points to it as the definitive explanation of why coherence and the orphan rule matter, in debates over Haskell, Rust traits, OCaml modules and Elm.
6 comments from Hacker News
The point is a little more subtle than this, or how the article made it out to be. Global coherence and confluence (which GHC attempts to enforce unless told otherwise) is great for refactoring and equational reasoning and (yes) mathematics and programming at large, as Ed Kmett's fantastic "Typeclasses v. the World" talk covers: this video Global uniqueness of instances (which GHC does NOT enforce) is bad for modular programming, or programming at large, which is a point some of the commenters here are making. [LINK] The submitted HN link here has a terrible title. What the author is proposing is enforcing typeclass laws, which is a great idea (but difficult in practice to implement). Practice and time has shown that lawless classes are the ones that people hate, the ones that don't add any benefit and in fact make it harder to reason about large Haskell programs. I hope people don't take away from this link that classes in Haskell are bad. Haskell is three things: pure, functional, and typeclasses. They're part of the identity of Haskell; they're the reason we set off on this wonderful journey into the uncharted oceans of functional programming back in 1990. Typeclasses are AWESOME. And they can be improved. Postscript: Kmett also has a package that persuades the compiler to let you have dynamically generates instances. It has the same user experience as local implicits, which I think a lot of people here are asking for: [LINK] λ> using (Monoid (+) 0) $ mappend mempty 12 12 GHC
Edward Kmett has a great explanation[1] of the considerations around this space. It's not that alternatives to the orphan rule are hard to implement, it's that they lead to things being much harder to reason about for the programmer. [1]: this video
I've seen Evan's talk. Evan confuses the presentation of features with the value of those features. (I suppose one could solve the difficulties people have in learning Mathematics by throwing out everything after Algebra I; another solution, however, might be to do a better job teaching the more difficult stuff.) Just because you shouldn't expose new programmers to advanced concepts on the first day doesn't mean they shouldn't be a part of the language. Similarly, the fact (<~) might confuse someone new to Elm isn't a reason for removing it from the language. I'm sympathetic to the concern that some code is too "clever" or dense; but Elm swings the pendulum too far. (Btw, type-classes are not incidental complexity: [LINK] this video )
AFAIUI modular implicits don't give you global uniqueness. While this can be "worked around" in some cases[0], it's not really possible in the general case, and global uniqueness is pretty essential for sanity when writing higher-level code[1]. [0] The paper gives set-union as an example. [1] this video . (Sorry for throwing video at you -- there's probably a write-up somewhere, but I'm in a bit of a rush, and this was the thing that came to mind.)
> [1] this video Now we just need a Haskell compiler which actually bothers to provide the "pretty essential for sanity" for global uniqueness. Currently, I count zero compilers in common use which do.