Proposed annotation system + dependency issue

[Simon Peyton-Jones]

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