base package (Was: GHC 7.8 release?)

[Simon Marlow]

On 20/02/13 17:12, Ian Lynagh wrote:
> On Fri, Feb 15, 2013 at 02:45:19PM +0000, Simon Marlow wrote:
>>
>> Remember that fingerprinting is not hashing.  For fingerprinting we
>> need to have a realistic expectation of no collisions.  I don't
>> think FNV is suitable.
>>
>> I'm sure it would be possible to replace the C md5 code with some
>> Haskell.  Performance *is* important here though - Typeable is in
>> the inner loop of certain generic programming libraries, like SYB.
>
> We currently just compare
>      hash(str)
> for equality, right? Could we instead compare
>      (hash str, str)
> ? That would be even more correct, even if a bad/cheap hash function is
> used, and would only be slower for the case where the types match
> (unless you're unlucky and get a hash collision).
 >
> In fact, we may be able to arrange it so that in the equal case the
> strings are normally exactly the same string, so we can do a cheap
> pointer equality test (like ByteString already does) to make the equal
> case fast too (falling back to actually checking the strings are equal,
> if they aren't the same string).

So it's not a single string, a TypeRep consists of a TyCon applied to 
some arguments, which themselves are TypeReps etc.

You could do pointer equality, and maybe that would work for the common 
cases.  But I don't see why we have to do that when fingerprinting works 
well and we already have it.  Why add a potential performance pitfall 
when we don't have to?

One other thing: it's useful to be able to use the fingerprint as an 
identifier for the contents, e.g. when sending Typeable values across 
the network.  If you can't do this with the fingerprint, then you need 
another unique Id, which is the situation we used to have before 
fingerprints.

Cheers,
	Simon