Re: patching SRFI 125 to compensate for SRFI 128 mustard John Cowan 12 May 2016 02:07 UTC

William D Clinger scripsit:

> The hash functions supplied by the sample implementation of SRFI 128
> are extremely slow (two to three decimal orders of magnitude slower
> than the corresponding hash functions of SRFI 126), and (unlike the
> hash functions of SRFI 126, which have no such limitations) are "not
> applicable to circular structure or to NaNs, or to objects containing
> any of these."

This without doubt is a Bad Thing.

> SRFI 128 is already final, so we can't fix it.

We can, in fact.  We have already issued minor errata for other final
SRFIs, and while this is more than minor, it is a less drastic change than
I have already proposed for SRFI 113, namely to use SRFI 128 comparators
rather than SRFI 114 comparators throughout.  If there is no objection
from the SRFI 113, 114, or 128 mailing lists (so far there is none),
the SRFI Editor has already agreed that a post-finalization note will
be added to the Status section of SRFI 113.

A similar note for SRFI 128 might read as follows:

    *Post-finalization note*:  Because of the extremely high cost of
    conforming to the first and third conditions of `default-hash`,
    implementers may disregard those conditions and examine only a
    bounded portion of the argument.

That done, there is no problem with replacing the sample implementation
of SRFI 128 with a more efficient one.

This is equivalent to your fourth solution (replace SRFI 128) but less
painful and slow (the SRFI approval process takes months).

John Cowan
Fundamental thinking is ha-ard.  Let's go ideology-shopping.
                        --Philosopher Barbie