[Haskell-cafe] Named function fields vs. type classes
Ralf.Laemmel at cwi.nl
Tue Dec 14 09:59:46 EST 2004
Major apologies for this repeated plug for HList.
Anyway, HLists  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 . The trade-offs are
explored a little bit on the OOHaskell slides and in the corresponding
code base .
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