Alex Shinn <xxxxxx@gmail.com> writes:

> On Thu, Oct 8, 2015 at 4:55 PM, Taylan Ulrich Bayırlı/Kammer
> <xxxxxx@gmail.com> wrote:
>
>     Alex Shinn <xxxxxx@gmail.com> writes:
>
>     > This is a clear example of piling feature on top of feature, in
>     > a way that creates more work for everybody.
>
>     Users will only ever do:
>
>     (make-hash-table equal-hash equal?)
>
>     and an implementation that needs a pair of equal-hash functions
>     will use its default pair of equal-hash functions in this case.
>
> You're making custom hash functions second class.
> They require more work and are used differently from
> the default hash functions.

Exactly. :-)

I want to prioritize the normal use-cases and the currently existing
Scheme implementations.  If we can support relatively obscure use-cases
as well, without disrupting normal use-cases, and without disrupting
compatibility with existing implementations, that's a nice bonus.

>     However, it puts a nontrivial burden on implementors, which is to
>     restructure their hash table code to manage salting in the new
>     way, by having a salt passed to hash functions everywhere.
>
> The lazy implementor can simply say:
>
> (define (equal-hash obj seed bound) (r6rs-equal-hash obj))

What I meant is the hash table code that now has to pass a salt to the
hash function of the hash table it receives.

Pseudocode of a high-level implementation:

    (define (hashtable-ref table key)
      (let ((hash-function (hashtable-hash-function table))
            (buckets (hashtable-bucket-vector table)))
        (let* ((bucket-count (vector-size buckets))
               (hash (hash-function key bucket-count))
               (index (modulo hash bucket-count))
               (bucket (vector-ref buckets index)))
          (bucket-ref bucket key))))

The true implementation of that is likely going to be somewhere deep in
a Scheme implementation, possibly written in C.  With your proposal,
this needs changing the (hash-function key bucket-count) part to pass a
salt.  It might not be a difficult change at face value, but it's
nevertheless an "intrusive" change to an implementation, and we will be
expecting this of every single Scheme implementation, most of which
already have their established low-level hash table support and are
happy with it.  People can support SRFI-69 and R6RS hashtables with a
bit of glue code in Scheme, on the other hand.

Changing the signatures of hash functions also means ABI breakage.

Taylan