Hi > 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.
Very true. If you define a class Binary2 with the single member binary2 you can let them write binary2 = inTermsOfBinary, binary2 = inTermsOfData or their own custom thing. > > 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. If the Show information doesn't display enough information to recreate an object with the same outward semantics as the original, that sounds like a bug in their Show. It also deals perfectly with your two points against Data - no abstraction is broken (i.e. Map works fine) and no internal data is exposed (i.e. type keys aren't printed). It's an ugly solution, but it might work quite well :-) My biggest worry would be performance - Read in particular is very slow. Thanks Neil ============================================================================== 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
