Data representation, maybe reflection, laziness
Ralf.Laemmel at cwi.nl
Sat Nov 1 15:38:53 EST 2003
The boilerplate style of generic programming  should be of help here.
For example, here you can see how to do a normal read and show:
We are also using this style to do decode and encode (think of bit
streams), or to read and show XML
(just working on this as we speak). Data.Generics allows you to obtain
access to constructors and type
information, which is crucial for versatile read/show functionality.
The rather inductive style underlying
"derivable type classes", which you mentioned, does not provide such
access, but could probably
be extended to do so.
You will also find a preliminary module Data.Generics.Reify at 
that illustrates indeed that there is some link to reflection if you
like this view.
One of the applications that really requires getting a handle on type
is test-set generation.
(The code base shown here is as of GHC 6.2, but
a simple version of Data.Generics was shipped with GHC 6.0.)
Mark Carroll wrote:
>People have been talking about transmitting Haskell values on the GHC
>users' list, and I wanted to ask some more general stuff, partly out of
>Ralf Hinze and Simon Peyton-Jones wrote an interesting paper on generic
>programming and derivable type classes. It looked like maybe programmers
>would be able to write their own "deriving xml" stuff and whatever, which
>looked great because, if there's not already one out there, I'd love to
>derive some read/show analogue automatically for data in some encoding
>that's very efficient to write and parse (i.e. not XML (-:).
>I was also wondering how the ability to write "deriving" stuff related to
>what one might think of as being reflection - that is, for example, could
>a definition of deepSeq be derived that automatically knows how to recurse
>into and traverse data structures and make sure everything's evaluated?
>This leads me to the point that little of the code I write needs laziness,
>but many of my unpleasant performance surprises come from laziness. I do
>find it hard to figure out where to put strictness annotations to actually
>make things work - for instance, I think it's laziness things that are
>causing my uses of Control.Exception.evaluate to actually work more by
>trial and error. No doubt it'll all grow clearer in time. Maybe I need
>"laziness annotations" instead. (-:
>Still, I was wondering what current thinking and directions were with
>regard to any of the above!
>Haskell-Cafe mailing list
>Haskell-Cafe at haskell.org
More information about the Haskell-Cafe