Changes to Data.Typeable

Simon Marlow marlowsd at
Thu Jul 7 17:44:34 CEST 2011

Hi folks,

In response to this ticket:

I'm making some changes to Data.Typeable, some of which affect the API, 
so as per the new library guidelines I'm informing the list.

The current implementation of Typeable is based on

   mkTyCon :: String -> TyCon

which internally keeps a table mapping Strings to Ints, so that each 
TyCon can be given a unique Int for fast comparison.  This means the 
String has to be unique across all types in the program.  Currently 
derived instances of typeable use the qualified original name (e.g. 
"GHC.Types.Int") which is not necessarily unique, is non-portable, and 
exposes implementation details.

The String passed to mkTyCon is returned by

   tyConString :: TyCon -> String

which lets the user get at this non-portable representation (also the 
Show instance returns this String).

So the new proposal is to store three Strings in TyCon.  The internal 
representation is this:

data TyCon = TyCon {
    tyConHash    :: {-# UNPACK #-} !Fingerprint,
    tyConPackage :: String,
    tyConModule  :: String,
    tyConName    :: String

the fields of this type are not exposed externally.  Together the three 
fields tyConPackage, tyConModule and tyConName uniquely identify a 
TyCon, and the Fingerprint is a hash of the concatenation of these three 
Strings (so no more internal cache to map strings to unique Ids). 
tyConString now returns the value of tyConName only.

I've measured the performance impact of this change, and as far as I can 
tell performance is uniformly better.  This should improve things for 
SYB in particular.  Also, the size of the code generated for deriving 
Typeable is less than half as much as before.

=== Proposed API changes ===


    mkTyCon is used by some hand-written instances of Typeable.  It
    will work as before, but is deprecated in favour of...

2. Add

    mkTyCon3 :: String -> String -> String -> TyCon

    which takes the package, module, and name of the TyCon respectively.
    Most users can just derive Typeable, there's no need to use mkTyCon3.

In due course we can rename mkTyCon3 back to mkTyCon.

Any comments?


More information about the Libraries mailing list