| > 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
