#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: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): I will try to follow this example in my DWARF stack tracing work. To recap, it seems like we have the following types, {{{#!hs -- | A Haskell module belonging to a package data Module moduleName :: Module -> String modulePackage :: Module -> Package -- | A Haskell package data Package packageName :: Package -> String packageKey :: Package -> PackageKey -- | A named definition in a Haskell module data Entity entityModule :: Entity -> Module entityName :: Entity -> String }}} Any preferences on where these should live? `GHC.Reflection` seems appropriate but perhaps a bit ambiguous given how overloaded "reflection" now is. In the case of DWARF stacktraces this will require that we are able to produce a `Module` for any given loaded Haskell module. It seems the easiest way to do this would be to simply inject a binding with a predictable name into each module at compile time. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10068#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler