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:13 PM, Matthias Felleisen <[email protected]> wrote: > > 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 with units. > > Haskell lacks both. There is a paper with Harper and Dreyer and a Haskell > person that tries to connect Haskell with ML at the type level, but not > comprehensively like the above. > > Yes, it is difficult to evaluate an abstraction without having worked with > them. Not even implementing them helps :-) Let me recommend an exercise: > > work thru the Sendai paper with an SML that finally provides recursive > functors. > https://www2.ccs.neu.edu/racket/pubs/#tacs94-cf > (This is the paper that inspired Units. I had coded everything in sml/nj > when I figured out that you couldn’t tie the knot with functors. So I > rewrote all of it with Scheme.) > > — Matthias > > > > > > > > > On Jan 22, 2018, at 1:22 PM, Alexis King <[email protected]> wrote: > > > > 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 the right thing > > is, since I have written precious little ML, and what I have written is > > certainly not enough to get a feel for how modules affect large program > > construction. It’s unfortunately difficult (perhaps impossible?) to get > > an understanding of the usefulness of an abstraction without using it > > oneself, so maybe I ought to just sit down and write some ML programs. > > > > Alexis > > > >> On Jan 21, 2018, at 1:26 PM, Matthias Felleisen > >> <[email protected]> wrote: > >> > >> 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 bit better with the > >> introduction of 'linking inference’ but it was too little too ate. The > >> other disadvantage of units concerns syntactic abstraction. You really > >> want to parameterize modules over their implementation language. > >> Shriram generalized units to unit/lang in his dissertation, but this > >> proved too difficult to implement. Matthew proposed to make modules > >> first-order, as opposed to first-class values, and this worked out > >> well. I still use units on rare occasions, for example to mimic > >> complex testing contexts and to deploy the same module-level > >> abstraction _twice_ in the same program. These situations are rare, > >> however. > >> > >> Historical note. ML programmers got it similarly wrong when they > >> pushed for “fully functorized” style. Once their compilation manager > >> came online, they abandoned this style too and simply allowed the > >> linker to connect structs as specified. I happened to be with these > >> MLers for a year, which inspired me for the unit-like abstraction when > >> we launched Racket/PLT Scheme. Functors are needed in the same > >> situations as units but had less expressive power (recursive/dynamic > >> linking). > >> > >> — Matthias > > > > > > -- > > You received this message because you are subscribed to the Google > Groups "Racket Users" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
