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?
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
1
3
Would you consider things like first class modules as being first class interfaces? If not, what are they missing?
1
1
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
Ahh gotcha, that makes sense! Yeah I do wish for nicer ways to work with module types (or dependent record types) as first class things.
Exactly. I want well-'typed' programs that manipulate modules types and/or dependent record types. The same way we can work magic with first class functions.
1
3
But then I get annoyed about how curried functions are so tied to argument order. I kind of want them to be a bit more like records in a way. 😅
1
2
Show replies