Update at the bottom!
In the last post I described Haskell’s current, limited notion of module identity. (It was none too exciting.) Now I’ll expand on that notion in our new package language. With a richer, more careful semantics of identity, we grant packages with the power of generic reusability!
What’s the difference between a “package” and a “module”? Though modules have evolved beyond their low-level origins into richly composable, type-based abstractions, packages are largely stuck in a Linux-like land of version ranges and imprecise specifications.
How can we bring packages up to speed with contemporary module systems? For my first big project, I’m investigating this question in the context of GHC Haskell and its package management system, Hackage/Cabal.
In MixML $\mathtt{let}$ binding of one module inside another is defined as syntactic sugar:
This definition highlights the minimalism of MixML (along with other definitions): one can express the entire ML module system in it. Unfortunately, the compactness of the language can hinder one’s understanding of these “macro-expressible” constructs. For my own benefit I wrote out the explicit elaboration rule for $\mathtt{let}$, so why not post it here:
