#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 alanz): == Summary of AZ understanding of the landscape == === Pros and cons of current approach === Pros Very non-invasive Programs that don't need the information don't touch it; this seems like the strongest advantage Can also bring out comments, tied to smallest enclosing SrcSpan having an annotation. The comments can be in Haddock mode, to aid tool processing. This makes use of the standard Opt_Haddock and Opt_KeepRawTokenStream settings. Cons Parser.y.pp is more complex Actually using the annotations is more complex === Pros and cons of embedded annotations as per Richard Eisenberg === Pros 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. Simpler parser cons Breaks lots of existing code, both in GHC and tools that make use of the AST. === Other thoughts === In terms of HaRe, the AST mainipulation will happen via ghc-exactprint. For this, the annotations are used as a starting point for processing. The mechanism intended in ghc-exactprint is to convert the absolute locations to relative locations, much as combinators in a pretty printer. This way when tooling modifies the AST, the output will honour the original layout as much as possible, given changes. Examples Lifting a declaration will preserve the layout of the original but dedented appropriately. Changing the name of an identifier, resulting in a longer or shorter name, just shifts things around naturally. {{{ foo x = x + y where fn a = a + 2 y = fn x }}} becomes {{{ foo xlong = xlong + y where fn a = a + 2 y = fn xlong }}} * The annotations can be easily accessed via a traversal of the appropriate kind. * There is a middle ground, where each AST element that has annotations tied to it in the current system has a single additional field containing [(SrcSpan,Ann]). Equally, the annotations retrieval function can provide all annotations attached to a given SrcSpan, via the current mechanism. * The most natural way to access the annotations is indirectly via a library such as HaRe or ghc-exactprint, as indicated by e.g. hlint, yi and IHaskell developers. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9628#comment:33 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler