Data representation, maybe reflection, laziness

[Ralf Laemmel]

Hi Mark,

The boilerplate style of generic programming [1] should be of help here.
For example, here you can see how to do a normal read and show:

http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/Data/Generics/Text.hs?only_with_tag=MAIN

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 [1]
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 
information
is test-set generation.

Regards,
Ralf

[1] http://www.cs.vu.nl/boilerplate/
(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
>mild ignorance.
>
>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!
>
>-- Mark
>_______________________________________________
>Haskell-Cafe mailing list
>Haskell-Cafe at haskell.org
>http://www.haskell.org/mailman/listinfo/haskell-cafe
>  
>