Hello,
Let me revive this by adding a data point on the usage of units.
I have always thought in my mind units as allowing you to have a
`plugin` system where you can plugin additional functionality at runtime.
However, I had never really gotten my hands dirty. I decided to have a
got under the f
Alexis, have you seen this?:
https://people.mpi-sws.org/~rossberg/1ml/
"ML is two languages in one: there is the core, with types and
expressions, and there are modules, with signatures, structures and
functors. Modules form a separate, higher-order functional language on
top of the core. There a
There's also Backpack, which adds something similar to ML's module system*
to Haskell, except at the package level:
https://plv.mpi-sws.org/backpack/backpack-paper.pdf
* It's more similar to Rossberg & Dreyer's MixML than it is to Standard ML
or OCaml's module systems.
On Mon, Jan 22, 2018 at 2:1
I think MLers complain about two things here:
— ML’s module system is basically a language that works at the type level. I
think OldCamlers mean this mostly.
— ML’s module system is also a typed lambda calculus whose basic values are
structs, aka, atomic modules. You can get a sense of this w
Thank you for this explanation.
I consider myself largely an outsider looking in on module systems, but
I often hear SML and OCaml programmers complaining, wondering when
Haskell is going to “get a real module system”. I’d like to do right
thing in Hackett if I can, but I don’t really know what th
Units were the wrong approach to everyday modularity.They were, and they are,
the correct solution to design problems such as those explained in our original
paper on the idea.
Units suffer from a large notational overhead for everyday use. The second
edition, due to Owens and Flatt, does a b
6 matches
Mail list logo
