[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 NeilMitchell):

 Alan and I debated this point, and I was the one who suggested the many
 data types approach (although I wouldn't go as far as saying I advocate it
 - I'm somewhat neutral). My concern was that if you do the dynamic
 approach you have to document each one of those strings, and the
 documentation has to be correct or the users won't have a clue what is
 going on, and if you update it all your clients will break and no one will
 realise. The documentation will basically be as long as the data types,
 but won't be statically checked on either side, and will very likely end
 up being wrong.

 Maybe a hybrid approach is to have location information for keywords like
 "of", "case", "where", "(" and ")". You can have a fixed static
 enumeration of keywords, so you have type safety, and every keyword is
 optionally in every AST. The number of keywords is relatively small, and
 which keyword is contained within each AST node doesn't require
 documenting (the lexical structure makes it pretty obvious). You end up
 with no requirement for fragile docs, one data type with a fairly small
 number of entries, and reasonable safety for both the producer and
 consumer.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9628#comment:17>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler