[GHC] #9628: Add Annotations to the AST to simplify source to source conversions

[GHC]

#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