[GHC] #10068: Make the runtime reflection API for names, modules, locations more systematic

[GHC]

#10068: Make the runtime reflection API for names, modules, locations more
systematic
-------------------------------------+-------------------------------------
              Reporter:  simonpj     |             Owner:
                  Type:  bug         |            Status:  new
              Priority:  high        |         Milestone:  7.12.1
             Component:  Compiler    |           Version:  7.8.4
              Keywords:              |  Operating System:  Unknown/Multiple
          Architecture:              |   Type of failure:  None/Unknown
  Unknown/Multiple                   |        Blocked By:
             Test Case:              |   Related Tickets:
              Blocking:              |
Differential Revisions:              |
-------------------------------------+-------------------------------------
 Currently in `base` we have

  * `GHC.SrcLoc`: the data type `SrcLoc` contains `srcLocPackage` and
 `srcLocModule`

  * `Data.Typeable.Internals`: the data type `TyCon` contains
 `tyConPackage`, `tyConModule` and `tyConName.

  * `GHC.Generics`: the data type `Datatype` contains `dataTypePackage`,
 `dataTypeModule` and `dataTypeName`

  * `Data.Data`: the data type `DataType` (yes the capitalisation differs!)
 contains a field `tycon :: String`, and there are functions `tyconModule
 :: String -> String`, and `tyconUQname :: String -> String`, for parsing
 that string and extracting the module name and tycon name.

  * `GHC.StaticPtr`: the data type `StaticPtrInfo` contains
 `spInfoPackageKey`, `spInfoModuleName`, `spInfoName` (all `String`s).  Oh,
 and `spInfoSrcLoc :: (Int,Int)` too!

 This is madness!  Five different representations for the same information
 in one package!

 Let's fix this by defining some shared data types, for

  * `Module` = `ModuleName` + package
  * `Entity` = `Module` + unqualified name

 There would be a tiresome changeover period; but `Typeable` and
 `StaticPtr` are in flux anyway.

 Would anyone be willing to lead on this?

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