Proposed annotation system + dependency issue
neil.mitchell.2 at credit-suisse.com
Tue Oct 14 06:57:08 EDT 2008
Both are valid problems. Indeed, Data /= Binary, but does provide handy
serialisation in a lot of cases.
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.
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).
> 1) What if a type is somewhat abstract and so has a Data
> instance which doesn't reflect the full internal structure of a type?
> Serialization becomes a lossy process (and gunfold wouldn't
> be defined in such a case anyway). I don't know how common
> this (anti?)pattern is in practice but I have used it myself.
> 2) (Somewhat related) What if a type contains some computed
> fields that should not be serialized? An example is TypeRep,
> which is "really" a rose tree of strings but as an
> optimization for comparison has unique numbers added to it by
> the constructor functions.
> Unfortunately these numbers are only unique for one run of
> the process, so what you really want to do is serialize the
> strings and then rebuild the TypeRep using its public
> interface. I don't think any Data based serialization
> mechanism could figure this out.
> IMHO Data really "means" something different than Binary, so
> you could probably find some more odd cases like the above..
> Maybe I'm worrying too much though.
> Cvs-ghc mailing list
> Cvs-ghc at haskell.org
Please access the attached hyperlink for an important electronic communications disclaimer:
More information about the Cvs-ghc