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

[Zoltan Somogyi]

2020-02-14 17:05 GMT+11:00 Julien Fischer<jfischer at opturion.com>:
>> Are you thinking of adding this as a typeclass constraint to the signature
>> of all the hash table operations, or just doing this to the init function,
>> and having it stash the hash function in the hash_table structure,
>> as we now do with the hash predicate? The former seems cleaner,
>> the latter has a simpler correctness argument for the proposition
>> that all call sites use the same typeclass instance and hence the same
>> hash function.
> 
> TBH, I hadn't thought that far ahead when I suggested it.
> I'll sketch out a more concrete proposal.

Ok. Note that the second alternative, extracting a function from a
typeclass_info for purpose other than calling it immediately, is not
something that ordinary users are supposed to do.

>> I would replace ht_cons with something like
>>
>> ht_more(K, V, K, V, kvlist(K, V)),
>>
>> where kvlist is defined by
>>
>> :- type kvlist(K, V)
>>    --->    kv_nil
>>    ;    kv_cons(K, V, kv_list(K, V)).
> 
> 
> I take it this was one motivation for your recent addition of such a
> type ;-)

The one and only.

Tell me when your changes to the hash_table code are done,
and I will make the change above replacing ht_cons.

Zoltan.