Proposed annotation system + dependency issue
simonpj at microsoft.com
Tue Oct 14 04:00:27 EDT 2008
| > 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.
More information about the Cvs-ghc