[Haskell] Re: [Haskell-cafe] ANN: Haddock version 2.1.0

David Waern david.waern at gmail.com
Fri May 2 11:37:59 EDT 2008

2008/5/2 Claus Reinke <claus.reinke at talk21.com>:
> > 2008/5/2 Simon Marlow <marlowsd at gmail.com>:
> >
> > > David Waern wrote:
> > >
> > > > No it doesn't, but it's on the TODO list. It needs a fix in GHC.
> > > >
> > > > By the way, I'm going to experiment with doing the parsing of comments
> > > > on the Haddock side instead of in GHC.
> > > > If that works out, we won't have to fix these things in GHC anymore.
> > > >
> > >
> > >  Sounds great - along the lines that we discussed on cvs-ghc a while
> back?
> > >
> >
> > Yes, something along the lines of separately parsing the comments and
> > recording their source locations, and then
> > trying to match them with the source locations of the AST nodes.
> >
>  yay!-) i hope that the haddock-independent part (parsing, preserving,
>  and accessing comments) becomes part of the GHC API in a form that would
> fix trac ticket #1886, then we could finally start writing (ghc) haskell
> source-to-source transformations without losing pragmas or comments!
>  losing layout would still be a pain, but that could be dealt with
>  later - at least the code would remain functional under some
>  form of (pretty . id . parse).

Hmm. When it comes Haddock, things are simpler than in a refactoring
situation, since we don't need to know exactly where the comments
appear in the concrete syntax. The original Haddock parser is very
liberal in where you can place comments. For example, it doesn't
matter if you place a comment before or after a comma in a record
field list, it is still attached to the previous (or next, depending
on the type of comment) field. I need to take another look at the
grammar to confirm that this is true in general, though. But anyway,
my plan was to do this entirely in Haddock, not do the "preserving"
part that you mention, and not do anything to GHC.



More information about the Haskell-Cafe mailing list