Email list hosting service & mailing list manager


Re: must SRFI-128 mustard be taken seriously? William D Clinger 09 May 2016 16:49 UTC

[If you get this message twice, I apologize.  I think I sent
it to the wrong mailing list six days ago.]

I have a question concerning the interpretation of SRFI 128's
mustardly specification of default-hash:

    When applied to a pair, it must return the result of hashing
    together the values returned by default-hash when applied to
    the car and the cdr.

    When applied to a list or vector, it must return the result
    of hashing together the values returned by default-hash when
    applied to each of the elements.

I believe that implies there exist mathematical functions f0, f1,
and f2 such that for all objects x and y that do not contain NaNs
or circular structure:

    (= (default-hash (cons x y))
       (f0 (default-hash x) (default-hash y)))

    (= (default-hash (vector x))
       (f1 (default-hash x)))

    (= (default-hash (vector x y))
       (f2 (default-hash x) (default-hash y)))

For Larceny, I would like to extend the domain of default-hash
to allow circular structures and structures that might contain
NaNs.  I would also like to improve upon the performance of the
sample implementation's default-hash, which is running three
decimal orders of magnitude slower than the equal-hash procedure
of SRFI 126 when applied to vectors of modest length.

The obvious way to accomplish that is to have default-hash call
equal-hash, which is required to terminate on all arguments.  In
Larceny, however, equal-hash is implemented by performing only a
bounded traversal of structured arguments.  That means there is
an object v of the form

    (vector (vector (vector ... (vector (vector (vector 0))) ... )))

that hashes to the same value h0 as the circular vector v0 computed
by

    (let ((v (vector 0)))
      (vector-set! v 0 v)
      v)

Similarly, h0 would be the hash of (vector v).  If my interpretation
of SRFI 128 is correct, then

    (= h0
       (default-hash (vector v))
       (f1 (default-hash v))
       (f1 h0))

so h0 must be a fixed point of f1.  In like manner, all of the hash
values that can be computed for all other circular structures would
have to be fixed points of f1.  That is a very strong constraint on
f1.

I am inclined to disregard the SRFI 128 mustard that places such
severe constraints on f0, f1, f2, and all the other implicit
functions that an implementation might use to combine the hashes
of a structured object's substructures, but I don't want to break
any code that actually depends upon that SRFI 128 mustard.

Is anyone relying upon that SRFI 128 mustard in some way that would
break if the default-hash procedure of SRFI 128 were implemented by
combining the hash value computed by SRFI 126 equal-hash with salt?
Can anyone even conceive of writing a program that wouldn't work if
default-hash and SRFI 126 equal-hash were the same procedure?

Will