[m-rev.] for review: rationalise hash functions across the standard library
jfischer at opturion.com
Tue Feb 11 14:19:22 AEDT 2020
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.
>>> should the hash table modules take a hash *function* instead of a
>> 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.
More information about the reviews