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:09 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