[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Seeking review of sets and hash tables proposals
"I've heard complaints about the messiness of passing two arguments,
one of which is optional, when creating a hash table. What about
having a procedure that accepts an equivalence predicate and a hash
procedure, and returns a procedure that behaves the same as the
equivalence predicate when called with two arguments, but when called
with zero arguments, returns the hash procedure."
It doesn't seem like a good idea.
- It is harder to explain and understand. It requires a new helper
procedure that returns a weird object.
- It is less efficient.
- It hurts type-checking: what is the type of this thing?
- It trivially simplifies hash-table constructions - assuming
you create a lot of them with the same equivalent/hash-pair.
It does not simplify the more frequent get/set functions.
- It can be easily simulated by the user, in multiple ways.
Note also some hash tables are sorted. For example:
That to me suggests another idea: Perhaps we can introduce
a "comparator" type which is a record with (optionally):
- an equality predicate
- an ordering operator (either like < or which returns -1/0/1)
(If the ordering operator returns -1/0/1 then it can provide
a default for equality predicate.)
- a hash operation
One or more of these can be "don't care".
A comparator object can be passed to a hash-table constructor, to
a sort routines, to a binary search routine, etc.
Just an idea that came to me - not sure it's a good one ...
Scheme-reports mailing list