Re: [Scheme-reports] Seeking review of sets and hash tables proposals

[Per Bothner <per@x>]

   "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:
   http://docs.oracle.com/javase/7/docs/api/java/util/SortedMap.html
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 ...
-- 
	--Per Bothner
per@x   http://per.bothner.com/

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