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!
In first-order module languages such as Haskell’s, the identity of a module is given solely by its programmer-written name, e.g. Http. When dealing with packages, the identity is augmented with that of its defining package, e.g. httplib-4.1:Http. These names induce a straightforward equivalence relation on modules: modules P1:M1 and P2:M2 are equivalent iff P1=P2 and M1=M2.
Why does module identity matter? Because type equivalence is a direct consequence of module equivalence. Two type constructors T1 and T2 are equivalent iff their original, defining modules are equivalent (and T1 and T2 are syntactically the same type constructor). Note that, e.g., the type constructors http-4.1:Http.Request and http-4.2:Http.Request are *not* equivalent since the two defining module identities are (slightly) distinct.
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.
