On Wed, Oct 14, 2015 at 6:09 PM, Taylan Ulrich Bayırlı/Kammer <xxxxxx@gmail.com> wrote:

It's not that existing implementations of hash functions don't take seed
arguments.  It's that existing implementations of hash tables don't pass
seed arguments to hash functions.

Ah, ok.  You can still provide wrapper hash-tables to get around
this, but I'm not particularly moved by implementation compatibility
arguments.  Existing library code matters more, but I'm willing to
break that in favor of clean design, and anyway the two proposals
are roughly equally compatible in this respect.

If I'm not mistaken, most custom hash functions ultimately delegate the
true hashing calculation to one of the built-in hash functions.

One counter-example is string-nfc=? which compares strings with
Unicode Normalization Form C.

In my experience this is the most common use-case for custom equality
and hashing.  I've never encountered any other use-case.

C++ hash tables allow custom hash functions, and I've made
extensive use of this for a variety of cases, although the most
common is simply hashing one or more fields of a class.

Even if the feature were rarely used, though, it should work
the same way as the builtin hash functions.

Wouldn't you agree that the small theoretical benefit to be gained in
those very rare use-cases is no justification to expect every Scheme
implementation to make a change to the core of their implementation?

Absolutely not.  "SRFI" stands for "Scheme Request For Implementation."
The whole point is to provide new, better, standard implementations.

From your explanation it sounds like SRFI_126_HASH_SEED is sufficient
for the described use-case, or am I missing something?

Yes, you missed:

> [...] An env variable
> is a poor way to handle this, since it places additional
> restrictions on the test running framework (e.g. there
> is currently no way in Snow to specify env vars to be
> set when running tests).

I think tests should be self-explanatory, not depending
on external factors, so that they can be run automatically
by tools and editors and such.

> And all of this is a minor point compared to the fact
> that the current SRFI-126 proposal is ugly, makes
> more work for everybody, and makes custom hashes
> second class citizens. I have no interest in this API.

"Ugly" on its own is purely subjective.  Please clarify.

Apart from the other points listed, I'd add the constructor
argument which can be either a function or pair of functions.
This is an unintuitive polymorphism, and arbitrarily limits to
either 1 or 2 but not more (when more can be useful).

-- 
Alex