Opened 21 months ago

Last modified 21 months ago

#14582 new bug

Review and improve the Typeable API

Reported by: simonpj Owned by:
Priority: normal Milestone:
Component: Compiler Version: 8.2.1
Keywords: Typeable Cc: Iceland_jack
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

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 (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 Typeable wiki page

Change History (2)

comment:1 Changed 21 months ago by Iceland_jack

Cc: Iceland_jack added

comment:2 Changed 21 months ago by bgamari

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.

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.

Note: See TracTickets for help on using tickets.