#9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297 | -------------------------------------+------------------------------------- Comment (by simonpj): Thank you. Now I understand that all this is focused solely on the source- location of keywords. (Previously I thought that there might be other client-specific information involved.) Could we then just take a moment to review the pros and cons of the proposed approach (the `ApiAnns` approach) compared with the earlier idea of just adding `SrcSpan` info to the `HsSyn` syntax tree itself. That is, like "Richard Eisenberg's response" and "SPJ response to concern re extra noise in AST" in the wiki page. I'll call that the "in-tree approach". Note that using record update syntax, a pass like the renamer would never need to explicitly match or mention the keyword location fields. Advantages of the `ApiAnns` approach * Very non-invasive * Programs that don't need the information don't touch it; this seems like the strongest advantage Advantages of the in-tree approach * The things you want are right there; no extra mappings to carry around, no lookups, no `AnnColon2` stuff. * Seems simple and uniform with the existing source locations. Eg. if a keyword 'do' could so be `mdo`, you might have a `Located Bool` to indicate. But if it's just `do` then we'd get `Located ()`, and then we drop it altogether. The in-tree story amounts to not dropping it. This is really a matter for our customers. Alan (Mr HaRE) is one. Do we have other known customers for this feature? What do they say? Or don't they case? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9628#comment:32 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler