Edward Kmett - Type Classes vs. the World

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

in “Haskell's Type Classes: We Can Do Better” · View on HN

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

in “This isn’t the way to speed up Rust compile times” · View on HN

It's been a while now, but I believe Ed Kmett covers some of this in his talk "Typeclasses vs The World" ▶ this video

in “Traits are a local maximum” · View on HN

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.)

in “An OCaml manifesto – Problems and what's needed for widespread adoption” · View on HN

> [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.

in “An OCaml manifesto – Problems and what's needed for widespread adoption” · View on HN

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 )

in “Making Elm faster and friendlier in 0.16” · View on HN