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