[m-rev.] for review: rationalise hash functions across the standard library

[Julien Fischer]

Hi Peter,

On Tue, 11 Feb 2020, Peter Wang wrote:

> On Tue, 11 Feb 2020 12:19:12 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
>>>
>>> Related: should we move towards using hash functions that return uints?
>>
>> Ultimately, the hash table implementation requires indexing into an
>> array and some of our target languages only support array indexing with
>> a signed integer type. (Indeed some of them require the index to be a
>> 32-bit type as well, IIRC, so maybe we should move towards hash funtions
>> that return an int32?)
>
> Hash functions are more naturally implemented with unsigned ints, at
> least in C, where left shifting of signed ints is fraught with
> undefined behaviour.

I don't have any objections to moving to unsigned integers.  I would
like whatever we end up with to be a little more well thought out
than what's currently present in the library.  Perhaps, we should move
to have hashable type class?

> If callers want fewer bits they can truncate it themselves, which they
> have to do anyway.

True.

>>> should the hash table modules take a hash *function* instead of a
>>> predicate?
>>
>> I wondered about that too.  Given that Ralph was so keen on using
>> fuctions everywhere else it's a bit odd that he decided to use a
>> predicate there ...
>
> The original implementation required two hash values.

Ah, that explains it!

> When I changed it to require only one hash value, I didn't change the
> hash predicates to functions.

I have no objection to changing it to a function; we should be able to
add wrappers that also preserve the existing interface.

Julien.