> - It is harder to explain and understand. It requires a new helper
> procedure that returns a weird object.
>
+1. By the principle of minimal surprise, I would prefer to either make do
with using two conventional procedures, or create a new type that behaves
like a conventional record.
> 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.
>
I like this idea, especially the part about reusing one representation of
orderedness ini all those places.
Actually a comparator can be defined by just a well-behaved < predicate and
a hash procedure, since
(> a b)
is equivalent to
(< b a)
and
(= a b)
is equivalent to
(and (not (< a b))
(not (< b a)))
Kevin Wortman
_______________________________________________
Scheme-reports mailing list
[email protected]
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
