2008/10/14 Mitchell, Neil <[EMAIL PROTECTED]>:
> One way round both issues you raise is to have a GhcTransform class,
> with two transform methods, one which is applied to the data before
> writing and the other after reading - giving the type a chance to
> "change" into another type supporting Data/Typeable, which is then
> serialised. So Maps (for example) would be converted to a list of pairs
> before serialisation, then serialised. The reader could then call
> fromList, and no abstraction is lost. Most types would be able to just
> use id for the transformation functions. I'm not sure how you'd
> implement this, but some combination of existentials should be possible.
Right, this is another interesting alternative. But since it requires
users to define their own instances all over the place anyway I would
almost be happier to provide our own version of the binary package to
users: they would be free to define their (de)serialization methods
using a default implementation derived from Data/Typeable if they knew
it was safe, and would have the flexibility to take another approach
if appropriate.
> If you want cheap and easy serialisation then Read/Show might even be an
> option - it has a number of issues, but can work in some cases (Yhc used
> it for Core files for a while).
Simon PJ also proposed this. Although it feels deeply wrong to me :),
It would do in a pinch, though it might suffer from some of the same
problems as Data: not enough information may be exposed in the Show
instance, for example.
As an added complication, I've just realised (in the course of
implementation) that our "Alternative 3" can't possibly work! When the
user writes this:
"""
{-# ANN foo MyAnnotationConstructor #-}
"""
GHC needs to have a way to serialize MyAnnotationConstructor. How does
it go about this without a Binary class to look up? Whoops..
All the best,
Max
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
