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
_______________________________________________
Glasgow-haskell-users mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
