[Haskell-cafe] Named function fields vs. type classes

Ralf Laemmel Ralf.Laemmel at cwi.nl
Tue Dec 14 09:59:46 EST 2004

Major apologies for this repeated plug for HList.

Anyway, HLists [1] are *exactly* designed for this sort of problem.
Well, one can also use existential quantification + bounded polymorphism;
with the shapes benchmark providing a good example [2]. The trade-offs are
explored a little bit on the OOHaskell slides and in the corresponding
code base [3].


[1] http://homepages.cwi.nl/~ralf/HList/
[2] http://www.angelfire.com/tx4/cus/shapes/haskell.html
[3] http://homepages.cwi.nl/~ralf/OOHaskell/

John Goerzen wrote:

>I often have a situation where I'm designing specialized components to
>do a more general task.   Examples could include mail folder code (maildir,
>mbox, etc), configuration file parsing, protocol handlers for URL
>accesses, logging backends, etc.
>For some of these, I've used a data object with named fields, each one
>of them being a function that performs various tasks (open connection to
>the URL, read data, whatever.)  So, I get a standard interface.  The
>advantage of this approach is that I can build a list containing all
>sorts of different data objects in it.
>For others, I've used typeclasses, and made the different specialized
>components a member of the typeclass.  This seems to provide a cleaner
>interface, and one that is more readily extended (maybe I want to
>support IMAP folders, and support all its searching capabilities too).
>On the other hand, it's difficult or impossible to make a list of a
>bunch of different types of things that have nothing in common save
>being members of the class.
>Is there any advice on the best way to do these things?
>Haskell-Cafe mailing list
>Haskell-Cafe at haskell.org

More information about the Haskell-Cafe mailing list