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

[Ralf Laemmel]

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].

Cheers,
Ralf

[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:

>Hi,
>
>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?
>
>Thanks,
>
>John
>
>_______________________________________________
>Haskell-Cafe mailing list
>Haskell-Cafe at haskell.org
>http://www.haskell.org/mailman/listinfo/haskell-cafe
>  
>