Conversation

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.
2
28
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
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?
1
2
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
3
Replying to and
When people talk about first class modules, they usually mean the *implementation* part (i.e. 'module struct' in ML) rather than interfaces (i.e. 'module sig'). That's the operational bias kicking in again, favouring the stuff that runs over the stuff that declares intent.
1
4
Show replies