On 26/05/13 06:48, Ray Dillinger wrote:

> I think user-supplied ordering functions are a relatively
> easy requirement for most users to fulfil, but hash functions
> that work as hash functions while mapping 'equal' things under
> a custom predicate to equivalent buckets are surprisingly
> subtle.  Requiring the user to supply one would make the
> library unfriendly to use and perhaps impossible in some
> cases.  IOW, providing a hash function, if there's a way
> to do it at all, should be optional but hopefully rewarded
> with (implementation-dependent?) better performance.  But
> providing at least a compatible ordering function if using
> a custom equivalence predicate is a reasonable requirement.

What is the use-case for user-defined hash functions?

I can see a few:

1) Hashing objects not supported usefully by the usual hash function,
such as things implemented as closures.

2) Hashing things that can already be hashed, but we want to make some
of them equivalent; considering some elements of a vector or record as
irrelevant, for instance.

3) You're a cryptographer or similar and have designed an awesome hash
functions that's faster/less collision-prone/whatever.

I think that cases 1 and 2 will be the most common - and might both,
perhaps, then best be handled by letting the user provide a "projection"
function that maps their values to an arbitrary hashable value, which is
actually hashed. The equivelance predicate can, then, be (equal?
(project a) (project b)), too.

>
> Ray
>

ABS

--
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports