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
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
