It's a very attractive approach, but comments can appear absolutely
anywhere in the concrete syntax, between any two tokens. How do we
decide where to attach these comments to the AST?
Allowing them anywhere but not ignoring them needs some thought for how
to parse them without going insane and complicating the grammar with
optional bits all over the place.
given that most AST clients assume that they don't have to deal
with comments, it might be best to preserve the comments, with
their src spans, and to store them outside the main AST, but
paired with it, as in your second suggestion.
then there ought to be lookup functions to check the comment
section for a comment immediately before or after a given AST
fragment.
i've created a ticket for this (there are surprisingly few ghc api
tickets), because i'd really like use the ghc api for processing
source code (eg, consider the recent discussion on replacing
layout with explicit braces, which should be near trivial, but..):
http://hackage.haskell.org/trac/ghc/ticket/1886
claus
Perhaps the lexer should accumulate comments and record their src spans.
Then in the parse action for a production it could collect the list of
accumulated comments and attach them to the AST. So the point is, the
comments would not be in the grammar at all, unlike in the current ghc
grammar which does have optional haddock comment tokens. Would that
provide enough information for haddock to work out whether the comments
are in the right places to be treated as haddock comments, and to which
parts of the AST comments attach?
I imagine it's pretty tricky and doing it in the context of ghc's high
performance lexer/parser even more so. Mind you, this kind of
infrastructure might be useful for other things like refactoring tools.
Duncan
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
