[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
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
 Type of failure:  None/Unknown      |  Unknown/Multiple
      Blocked By:                    |               Test Case:
 Related Tickets:                    |                Blocking:
                                     |  Differential Revisions:
-------------------------------------+-------------------------------------

Old description:

> 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?

New description:

 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!

  * `GHC.Stack.ccSrcSpan :: Ptr CostCentre -> IO CString` stores a source
 location in a C structure, and returns it as a `CString`.

 This is madness!  Six 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?

--

Comment (by simonpj):

 Well spotted.  Do you feel like helping out with this?!

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