ML-style module systems are lots of fun haha
Conversation
Being able to separate interfaces from implementations, and hide internal representations is so powerful. I wish more people knew about this stuff! I find OCaml's implementation clunky in many ways, but yeah, I still really like it in general. :)
2
1
6
Standard ML and Ocaml have the best module systems I've ever come across, and cannot be praised without mentioning functors. I've loved them even more since Ocaml added local opens (which Merlin supports beautifully).
1
Now I just want to know how typeclasses can be added in a way that respects the sort of modularity that Ocaml demands, whilst respecting canonicity and preventing orphans. Not sure where we're at with those constraints.
2
Modular implicits seem promising (even if more design work is required). Not the biggest fan of global canonicity, but I do like local canonicity, which is part of that design IIUC. What do you mean by ‘preventing orphans’?
1
We could have a version of Haskell where orphan instances are banned outright. I've got a sense that this would be complicated in an ML-style module system, but my thoughts aren't very clear.
1
Rust has rules to prevent this – it might be interesting to look there. Not sure what rules ‘modular typeclasses’ enforced, but maybe you could come up with a variant that works more like Rust.
1
But yeah I feel like enforcing these kinds of global rules go against the things that make modules great, so I'm not the biggest fan if I'm completely honest? Like, it puts limits on the modules users can make, in order to enforce the global state of the package ecosystem.
2
Yes. One of the goals of module system is not to require a global check on the system. It needs to be, well, modular.
Maybe canonicity is something I could give up. I think it would help keep typeclasses and modules orthogonal.
1
For e.g. the way you keep the ordering of keys in a binary tree consistent in Ocaml is to have a Tree functor which you apply to an Order module, giving a tree type that depends on that module.
In Haskell, you use canonicity of Ord instances.
I'm not sure I want both options.
1
1
Replying to
Yeah, applicative functors is brought up as an alternative to canonicity in the Modular Implicits paper: arxiv.org/abs/1512.01895 - see “4.4: An alternative to canonicity as a feature”.
“COCHIS: Stable and coherent implicits” is another interesting paper in this space (I've not really looked too closely at it though):
1