[GHC] #10068: Make the runtime reflection API for names, modules, locations more systematic
GHC
ghc-devs at haskell.org
Fri Apr 17 16:12:48 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:
Type of failure: None/Unknown | Unknown/Multiple
Blocked By: | Test Case:
Related Tickets: | Blocking:
| Differential Revisions:
-------------------------------------+-------------------------------------
Comment (by ezyang):
I suppose not; it is only related. An example is the `NameG` constructor:
{{{
Prelude Language.Haskell.TH Language.Haskell.TH.Syntax> :t NameG
NameG :: NameSpace -> PkgName -> ModName -> NameFlavour
Prelude Language.Haskell.TH Language.Haskell.TH.Syntax> :info PkgName
newtype PkgName = PkgName String
-- Defined in `Language.Haskell.TH.Syntax'
instance Eq PkgName -- Defined in `Language.Haskell.TH.Syntax'
instance Ord PkgName -- Defined in `Language.Haskell.TH.Syntax'
Prelude Language.Haskell.TH Language.Haskell.TH.Syntax> :info ModName
newtype ModName = ModName String
-- Defined in `Language.Haskell.TH.Syntax'
instance Eq ModName -- Defined in `Language.Haskell.TH.Syntax'
instance Ord ModName -- Defined in `Language.Haskell.TH.Syntax'
}}}
So, the suggestion is that with a unified reflection API, it would make
sense to make TH also accept this information. But maybe this is just a
separate concern!
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10068#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list