Claus Reinke wrote:
Perhaps a better solution would be to represent the documentation by
Dynamics in GHC's abstract syntax, and to pass in the functions that
parse
and rename the documentation annotations, perhaps in the DynFlags.
Good idea. Sounds like it would work to me.
just curious: what makes this tighter integration, or the use
of Dynamics, necessary?
The abstract syntax contains the Haddock documentation. There are
alternatives to this, but I couldn't think of an attractive alternative,
perhaps you can.
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
