"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 [email protected] http://per.bothner.com/ _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
