Re: Best practices for modular programming in Haskell

Benjamin Pierce wrote:
For someone coming to Haskell from an OCaml background, one of the hardest things to get used to is the somewhat more bare bones module system that Haskell provides. ... This works fine as long as what you're exporting is just values, but it's awkward for types, since there is no way to *declare* a type (e.g., giving just its kind) without *defining* it.
Actually Haskell fully matches the module system of OCaml -- and then adds some. Haskell provides both generative and applicative (recursive) functors. The following two messages elucidate the correspondence http://www.haskell.org/pipermail/haskell/2004-August/014463.html http://www.haskell.org/pipermail/haskell/2004-September/014515.html The end of the first message gives the translation dictionary: from OCaml/ML module terminology to Haskell terminology. I have recently found out that the translation works the other way around, too. Both messages are doubly-literate code: messages can be loaded into OCaml or into a Haskell system. Regarding the specific question of hiding a type: oftentimes declaring a class and exporting it suffices. (forall a.C a => a) is an `abstract' type in Haskell. If the type to abstract has a kind *->*, we can write (forall a.C a => a b), etc. If we really want to prevent the user from ever knowing the details of the implementation, existential quantification (along with the typeclass) does the trick. That trick incidentally permits `self-tuned' data structures, the simple example of which is http://www.haskell.org/pipermail/haskell/2005-February/015356.html

Actually Haskell fully matches the module system of OCaml -- and then adds some. Haskell provides both generative and applicative (recursive) functors. The following two messages elucidate the correspondence
http://www.haskell.org/pipermail/haskell/2004-August/014463.html http://www.haskell.org/pipermail/haskell/2004-September/014515.html
Wow. Do people actually develop significant bodies of code in this style? - Benjamin

Yes. Its actually very easy once you get how instance resolution occurs and how constraints work. I have used this style to code a database interface, and am using the OOHaskell style (which is related to this kind of stuff) for an application server (was a SOAP server, but might migrate to the new WebServices standards). Infact there is only one real limitation, and that is you cannot (easily) lift an arbitrary IO value to a type. (You can do this but there must be a limit to the value). This does seem solvable however - but not with the current ghc/hugs architecture. To lift a value to a type the code depending on that type cannot be compiled/type-checked until the value is known. This would be ideally suited to a JIT compiler. Keean. Benjamin Pierce wrote:
Actually Haskell fully matches the module system of OCaml -- and then adds some. Haskell provides both generative and applicative (recursive) functors. The following two messages elucidate the correspondence
http://www.haskell.org/pipermail/haskell/2004-August/014463.html http://www.haskell.org/pipermail/haskell/2004-September/014515.html
Wow.
Do people actually develop significant bodies of code in this style?
- Benjamin
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (3)
-
Benjamin Pierce
-
Keean Schupke
-
oleg@pobox.com