seeds Alex Shinn (08 Oct 2015 05:03 UTC)
Re: seeds taylanbayirli@xxxxxx (08 Oct 2015 07:55 UTC)
Re: seeds Arthur A. Gleckler (08 Oct 2015 17:46 UTC)
Re: seeds taylanbayirli@xxxxxx (08 Oct 2015 19:38 UTC)
Re: seeds Arthur A. Gleckler (08 Oct 2015 21:47 UTC)
Re: seeds taylanbayirli@xxxxxx (09 Oct 2015 08:09 UTC)
Re: seeds Kevin Wortman (09 Oct 2015 17:18 UTC)
Re: seeds taylanbayirli@xxxxxx (09 Oct 2015 18:33 UTC)
Re: seeds Kevin Wortman (13 Oct 2015 17:36 UTC)
Re: seeds taylanbayirli@xxxxxx (13 Oct 2015 18:28 UTC)
Re: seeds Alex Shinn (14 Oct 2015 01:59 UTC)
Re: seeds taylanbayirli@xxxxxx (14 Oct 2015 09:17 UTC)
Re: seeds taylanbayirli@xxxxxx (14 Oct 2015 10:06 UTC)
Re: seeds Alex Shinn (16 Oct 2015 01:23 UTC)
Re: seeds taylanbayirli@xxxxxx (16 Oct 2015 13:34 UTC)
Re: seeds Alex Shinn (16 Oct 2015 23:48 UTC)
Re: seeds taylanbayirli@xxxxxx (17 Oct 2015 12:08 UTC)
Re: seeds Alex Shinn (17 Oct 2015 13:12 UTC)
Re: seeds taylanbayirli@xxxxxx (17 Oct 2015 14:09 UTC)
What SRFIs are for John Cowan (17 Oct 2015 14:41 UTC)
Re: What SRFIs are for taylanbayirli@xxxxxx (17 Oct 2015 15:56 UTC)
Re: What SRFIs are for John Cowan (17 Oct 2015 16:55 UTC)
Re: What SRFIs are for taylanbayirli@xxxxxx (17 Oct 2015 18:08 UTC)
Re: What SRFIs are for John Cowan (17 Oct 2015 18:51 UTC)
Re: seeds John Cowan (15 Oct 2015 17:49 UTC)
Re: seeds Alex Shinn (09 Oct 2015 02:54 UTC)
Re: seeds taylanbayirli@xxxxxx (09 Oct 2015 07:59 UTC)
Re: seeds John Cowan (15 Oct 2015 17:51 UTC)
Re: seeds taylanbayirli@xxxxxx (15 Oct 2015 23:08 UTC)
Re: seeds John Cowan (16 Oct 2015 13:09 UTC)
Re: seeds taylanbayirli@xxxxxx (16 Oct 2015 14:01 UTC)

Re: seeds taylanbayirli@xxxxxx 09 Oct 2015 07:59 UTC

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