Hi 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). Thanks Neil > 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. > > Cheers, > Max > > _______________________________________________ > Cvs-ghc mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/cvs-ghc > > ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
