John Cowan <xxxxxx@mercury.ccil.org> writes:

> Taylan Ulrich Bayırlı/Kammer scripsit:
>
>> 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.
>
> Scheme is unique in that it has always accepted custom hash functions.
> CL does not, Python does not, Perl does not, JS does not.  I think this
> is not only an important feature to preserve, but it is important to
> allow existing custom hash functions to continue to work, if not most
> securely.

Sure, I'm not removing that functionality.  I could say I see custom
hash functions like the one in my "student identity" example to be a
"normal" use-case.  (In some other languages one achieves a similar
effect by implementing a hash method in a class conforming to a hashing
interface.  At least in Objective-C that's the idiomatic way to do it,
and I use that regularly in boring, occupationally written code.  I
suspect it's similar in Java and maybe also Python, possibly CL too if
CL's 'equal-hash' function is a generic.)

I just don't see much of an improvement in changing hash function
signatures to something entirely novel, when '(obj, [bound]) -> int'
works perfectly fine and is familiar for programmers and more compatible
with existing implementations.

Taylan