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/Generi... 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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe