base package (Was: GHC 7.8 release?)
marlowsd at gmail.com
Thu Feb 21 10:58:14 CET 2013
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
> 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
More information about the Glasgow-haskell-users