+1 from me. it'll break about 40-50 of my modules, but the changes are pretty mechanical.<br><br><div>-Edward</div><div><br><div class="gmail_quote">On Thu, Jul 7, 2011 at 11:44 AM, Simon Marlow <span dir="ltr"><<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi folks,<br>
<br>
In response to this ticket:<br>
<br>
<a href="http://hackage.haskell.org/trac/ghc/ticket/5275" target="_blank">http://hackage.haskell.org/<u></u>trac/ghc/ticket/5275</a><br>
<br>
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.<br>
<br>
The current implementation of Typeable is based on<br>
<br>
mkTyCon :: String -> TyCon<br>
<br>
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. "<a href="http://GHC.Types.Int" target="_blank">GHC.Types.Int</a>") which is not necessarily unique, is non-portable, and exposes implementation details.<br>
<br>
The String passed to mkTyCon is returned by<br>
<br>
tyConString :: TyCon -> String<br>
<br>
which lets the user get at this non-portable representation (also the Show instance returns this String).<br>
<br>
So the new proposal is to store three Strings in TyCon. The internal representation is this:<br>
<br>
data TyCon = TyCon {<br>
tyConHash :: {-# UNPACK #-} !Fingerprint,<br>
tyConPackage :: String,<br>
tyConModule :: String,<br>
tyConName :: String<br>
}<br>
<br>
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.<br>
<br>
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.<br>
<br>
=== Proposed API changes ===<br>
<br>
1. DEPRECATE mkTyCon<br>
<br>
mkTyCon is used by some hand-written instances of Typeable. It<br>
will work as before, but is deprecated in favour of...<br>
<br>
2. Add<br>
<br>
mkTyCon3 :: String -> String -> String -> TyCon<br>
<br>
which takes the package, module, and name of the TyCon respectively.<br>
Most users can just derive Typeable, there's no need to use mkTyCon3.<br>
<br>
In due course we can rename mkTyCon3 back to mkTyCon.<br>
<br>
Any comments?<br>
<br>
Cheers,<br>
Simon<br>
<br>
______________________________<u></u>_________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/<u></u>mailman/listinfo/libraries</a><br>
</blockquote></div><br></div>