#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