All of us who teach Haskell (and that includes me, in practice) get badly burned when we have to cope with the way the language and library move on. This is especially funny for me, as the inventor of much of the structure that has caused the library disturbance.
Conversation
If only that fucker McBride hadn’t noticed that Applicative was a useful generalization of Monad, we’d still be pretending that Monads weren’t Functors. Yes, it’s my fault. Yes, it hurts. Yes, you asked for it.
1
1
29
It serves a useful purpose nevertheless: pointing out that how we build our libraries is brittle (not just in Haskell). Hierarchies of any kind don't tend to survive having a new member added 'in the middle'. This is dumb engineering.
2
1
11
Some of my work on generating library code has been linked to that problem. My solutions are not good ones, BUT at least I show that solutions do exist. As a faint hope that others would take up the cause and find better solutions. I'm still waiting.
1
4
I'd love to see a future where we can make use of these solutions! I'd love to live in a world where we can evolve libraries in a less brittle way than seems to be possible with type classes.
1
1
Well, clarifying: type classes as they exist in languages like Haskell and Rust. Not sure how module systems compare for these kinds of changes? I'd imagine there are still issues?
type classes (and module types and traits) are all variants of interfaces along with extra rules for conformance and/or resolution. The first step is to revisit interfaces and how to build & compose them. In fact, interfaces should be first class, but they aren't (yet).
2
1
3
Would you consider things like first class modules as being first class interfaces? If not, what are they missing?
1
1
Show replies