should haddock.ghc be a sub-repo of ghc?

[Claus Reinke]

> The abstract syntax contains the Haddock documentation.  There are 
> alternatives to this, but I couldn't think of an attractive alternative, 
> perhaps you can.

i'm not sure about attractive, but since every haddock comment 
is by design also a comment, and many ghci api clients would be
interested in those, i thought the abstract syntax would just 
contain uninterpreted comments.

then tools that are interested in documentation, like haddock 
or refactorers, or whatever, could use the api to get abstract
syntax and symbol table, and do whatever additional interpretation
they need to do - no need for ghc to know anything more than
"here is a comment".

if the comments are stored as ghc's shared strings, haddock
could map them to whatever internal document type it prefers,
without ghc having to handle haddock dynamics.

less integration, but more modularity - haddock.ghc would
still have the advantage of being able to parse anything that
ghc can handle by sharing its frontend, but ghc would not 
need to handle anything haddock-related in any special 
way. is that too naive?

claus
 
> Now, given that HsSyn contains documentation, either (a) the type of the 
> documentation must be visible to HsSyn, which forces either the current 
> solution of putting the HsDoc type into GHC, or using Dynamic, or (b) HsSyn 
> is parameterised over the type of the documentation, which doesn't work 
> because the whole GHC API would have to be parameterised and overloaded (or 
> you need module functors, which we don't have).
> 
> Cheers,
> Simon