Hi, There is an alternative 4:
Require Data/Typeable instances for all items, then using runtime reflection provided by Data serialise the values into binary (or however else you want them). * You don't get any additional dependencies (other than perhaps SYB, which I hope you are going to add for the GHC API data types anyway). * You can control the format of the serialisation perfectly, and in a version independent way. * You can add type structure checksums to stop changed types with the same name being messed around - which should eliminate all heisenbugs from stale .hi files. * Everyone can write deriving Data/Typeable with automatic deriving. * Data/Typeable seems a much more natural pair of instances than Typeable/Binary * Data has been around and solidified for a lot longer time period, and isn't likely to change in incompatible ways. * You can serialise things into XML etc. without any interface change, should your requirements change. There is one single disadvantage: * Serialisation will be slower. Not massively slower, but a bit. And hopefully it isn't a bottleneck anyway. I previously wrote binary serialisation code on top of SYB, and it wasn't very hard at all. Thanks Neil > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Simon Peyton-Jones > Sent: 14 October 2008 9:00 am > To: Duncan Coutts; Max Bolingbroke > Cc: [email protected] > Subject: RE: Proposed annotation system + dependency issue > > | > Simon M mentioned this. However, the unique problem with > Binary is > | > that ghc will exports an API that mentions the Binary class: > | > > | > """ > | > -- For normal GHC API users: > | > getAnnotations :: (Typeable a, Binary a) => Name -> GHCM [a] > | > > | > -- Only for plugins adding their own annotations: > | > getAnnotations :: (Typeable a, Binary a) => Name -> CoreM [a] > | > putAnnotations :: (Typeable a, Binary a) => Name -> a -> CoreM () > | > """ > | > | Ok, but it needn't, eg: > | > | type Serialise a = a -> ByteString > | type Deserialise a = ByteString -> a > | > | -- For normal GHC API users: > | getAnnotations :: Typeable a => Deserialise a -> Name -> GHCM [a] > | > | -- Only for plugins adding their own annotations: > | getAnnotations :: Typeable a => Deserialise a -> Name -> CoreM [a] > | putAnnotations :: Typeable a => Serialise a -> Name -> a > -> CoreM () > > Indeed -- that's Alternative 3 on > http://hackage.haskell.org/trac/ghc/wiki/Annotations. > > I dislike Alternative 3 because it makes the following > scenario entirely plausible: > > - A plugin uses binary-2.1 to serialise stuff into Foo.hi > - A GHC api client uses binary-3.0 to deserialise it > (probably without realising that they are using the > "wrong" Binary) > > Result: extreme broken-ness at runtime. And guess who gets > blamed? GHC. (I feel a bit like Windows here :-) > > An advantage of baking a particular Binary library into GHC > is that we'll always, guaranteed, use *that* Binary library > for serialisation and deserialisation. (GHC already can't > read .hi files written by earlier GHCs, so that's unchanged.) > > But still no alternative seems perfect, hence this debate. > > Simon > > _______________________________________________ > 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
