#2836: Data.Typeable does not use qualified names
---------------------------------+------------------------------------------
Reporter: guest | Owner:
Type: feature request | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 6.10.1
Severity: minor | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Os: Unknown/Multiple
Architecture: Unknown/Multiple |
---------------------------------+------------------------------------------
Changes (by simonpj):
* difficulty: => Unknown
Old description:
> The TyCon in Data.Typeable does not provide the qualified type name.
> This can be very annoying if you try to use a TypeRep as a stored
> representation of a type (within a run it's OK with the equality on
> TypeRep).
>
> I suggest that the TyCon be enhanced to contain a qualified name, but
> that the current API be maintained, except for adding some new functions
> to access qualified name.
>
> If prodded I could provide the Data.Typeable implementation and the fix
> to ghc.
New description:
The !TyCon in Data.Typeable does not provide the qualified type name.
This can be very annoying if you try to use a !TypeRep as a stored
representation of a type (within a run it's OK with the equality on
!TypeRep).
I suggest that the !TyCon be enhanced to contain a qualified name, but
that the current API be maintained, except for adding some new functions
to access qualified name.
If prodded I could provide the Data.Typeable implementation and the fix to
ghc.
Comment:
Your suggestion sounds plausible to me.
There is some design to do first. Currently `Data.Typeable.TyCon` is
really just a string (plus a key for comparison). Maybe you want three
strings?
* The package name
* The module name
* The !TyCon name
plus accessor functions.
Another possibility (unavailable when `Data.Typeable` was designed I
think) would be to use a Template Haskell name:
`Language.Haskell.TH.Syntax.Name`. After all, `Data.Typeable` is just
another form of reflection, like TH. I'm not sure what the tradeoffs are
though. For example, TH names don't have a key for fast comparison. (But
the keys are quite a nuisance in some ways because they may differ from
run to run.)
I suggest you progress this via the library process: make proposals,
encourage discussion. Actually implementing it will not be hard.
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2836#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
