[GHC] #10068: Make the runtime reflection API for names, modules, locations more systematic
GHC
ghc-devs at haskell.org
Tue Aug 25 08:21:01 UTC 2015
#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
More information about the ghc-tickets
mailing list