more default hash functions Alex Shinn (16 Oct 2015 01:57 UTC)
Re: more default hash functions taylanbayirli@xxxxxx (16 Oct 2015 13:53 UTC)
Re: more default hash functions Alex Shinn (16 Oct 2015 14:30 UTC)
Re: more default hash functions taylanbayirli@xxxxxx (16 Oct 2015 16:12 UTC)
Re: more default hash functions Alex Shinn (16 Oct 2015 23:50 UTC)
Re: more default hash functions taylanbayirli@xxxxxx (17 Oct 2015 12:30 UTC)

Re: more default hash functions taylanbayirli@xxxxxx 17 Oct 2015 12:30 UTC

Alex Shinn <xxxxxx@gmail.com> writes:

> On Sat, Oct 17, 2015 at 1:12 AM, Taylan Ulrich Bayırlı/Kammer
> <xxxxxx@gmail.com> wrote:
>
>     Sorry, I still don't understand. If an implementation has an
>     internal eq-hash whose results change between GC runs, then
>     wouldn't (define symbol-hash eq-hash) be an illegal implementation
>     for symbol-hash?
>
>
> Think about how you would implement symbol-hash in
> terms of the R6RS hash table library.

(rnrs hashtables (6)) already exports symbol-hash.  If it didn't and I
had to implement it in Scheme, I guess I would use symbol->string and
string-hash as an inefficient compatibility shim.

I just discovered by trial and error that that's exactly how Larceny
implements it!

$ larceny -r7rs
> (import (rnrs hashtables))
> (symbol-hash 'foo)
14095
> (string-hash "foo")
14095

And likewise for any symbol/string.

I guess t could have implemented that in a way like you suggested, by
storing an eagerly computed hash value in each symbol or so.

It could also cheat a bit and turn (make-hashtable symbol-hash eq?) into
an eq? hash table.  (Since one cannot access the bucket vector of a hash
table, it should be fine to secretly use a different hash function than
what's passed to make-hashtable / returned from hashtable-hash-function,
right?)

Am I missing something?

Taylan