[GHC] #14582: Review and improve the Typeable API
#14582: Review and improve the Typeable API -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: Typeable | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This ticket is to track improvements in the `Typeable` API There are a number of points I'm uncomfortable about * `Data.Typable` is presumably meant to be the public API, and is fairly small. But `Data.Typeable.Internal` has a much larger API, which includes pattern synonyms and suchlike that appear to be for the benefit of clients, not just internal use. * The `Typeable` API has `type TypeRep = I.SomeTypeRep` which is different to the type-indexed `data TypeRep a` defined in `Data.Typeable.Internals`. This is exteremly confusing. Perhaps this is intended to be temporary, while we are moving over to the new type-indexed representation. But then what's the transition plan? * I cordially dislike this stuff about `IsApplication` in `Internals` ([https://git.haskell.org/ghc.git/commitdiff/1acb922bb1186662919c1dbc0af596584... this commit]). It's hard for me to understand what's going on. I believe that the two pattern synonyms `App` and `Con` are supposed to be exhaustive -- if so, let's just write a COMPLETE pragma. * The code has many uses of `unsafeCoerce`, whereas the drive of our "Typed reflection in Haskell" paper was to reduced the size of the trusted code base. I'd like to see a comment on each of those uses of `unsafeCoerce` to explain. * Do we really need `Con'` as well as `Con`? * The API could do with some careful documentation, in Haddock, but perhaps also an accomanying wiki page. It's tricky stuff. Here's the [wiki:Typeable Typeable wiki page] -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14582 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14582: Review and improve the Typeable API -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14582#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
`Data.Typable` is presumably meant to be the public API, and is fairly small. But `Data.Typeable.Internal` has a much larger API, which includes
#14582: Review and improve the Typeable API -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): pattern synonyms and suchlike that appear to be for the benefit of clients, not just internal use. As noted in its documentation, `Data.Typeable` is the home of the old, non-type-indexed `Typeable` mechanism whereas the new mechanism lives in `Type.Reflection`. The goal of this design was to preserve compatibility with existing programs by minimizing the changes in `Data.Typeable`. All of the new bits, including the pattern synonyms (which are really only useful with the type-indexed variant), are exposed in `Type.Reflection`.
This is exteremly confusing. Perhaps this is intended to be temporary, while we are moving over to the new type-indexed representation. But then what's the transition plan?
My original intent was for this to be permanent. While working on the new `Typeable` implementation I viewed `Data.Typeable` and `Type.Reflection` as two mechanisms that, which while they happened to share implementation, serve rather different purposes. However, the name `TypeRep` seems to be quite applicable in both cases. I can see how the naming may be confusing and ideally the quantified variant would be called `SomeTypeRep` but I'm skeptical that deprecating the `Data.Typeable.TypeRep` synonym is worth the breakage that it would cause. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14582#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC