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 <matth...@felleisen.org> 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 <lexi.lam...@gmail.com> 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 > >> <matth...@felleisen.org> 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 racket-users+unsubscr...@googlegroups.com. > > 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 racket-users+unsubscr...@googlegroups.com. > 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 racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
