On Tue, 2007-11-13 at 14:12 +0000, Claus Reinke wrote: > 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?
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. 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 Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
