[R6RS] proposed generalizations of equal?
William D Clinger
will at ccs.neu.edu
Tue Jun 27 15:42:11 EDT 2006
Regarding two proposed generalizations of equal?, here are
some empirical data and an important technical consideration.
First with regard to the proposed generalization to two or
more arguments. I used fgrep to search 72784 lines of the
core Larceny code base: the Twobit compiler, all eight code
generators (including four that haven't been released), the
R5RS libraries, and the SRFI libraries. (I wrote about a
third of that code, Lars Hansen and other graduate students
wrote about a third, and third parties wrote about a third.)
I found 567 lines that contained a call to eq?, 107 that
call eqv?, and 71 that call equal?. I did not find a single
example in which the proposed extension to more than two
arguments would have been useful.
My conclusion is that the proposed extension is not worth
the paper on which it would be written, let alone the time
that would be required to implement it.
I propose the following general rule: For total orders,
we generalize the comparison predicates to two or more
arguments, but we don't do that for equality predicates
in general.
Secondly, with regard to the proposed generalization of
equal? to an equalp? predicate that would take an extra
procedure, a predicate to be used to compare objects that
aren't pairs or vectors, I'd like to withdraw that proposal.
There are two problems with it. One is that programmers
would want to supply a binary predicate that recursively
compares records or other structures, but that won't work
because the recursive comparison of records would have to
use the same hash table that was created by the original
call to equalp?. To make it work, the predicate would
have to take the hash table as a third argument, and pass
that hash table back to equalp? whenever it makes a
recursive call to equalp?. Alternatively, the third
argument to equalp? would be a procedure that takes a
specialized equal? as argument and returns a binary
predicate. In my opinion, either interface is too complex
and error-prone for inclusion in the R6RS.
Another problem is that equalp? couldn't be guaranteed to
terminate. That would depend upon the third argument, so
we would end up with a procedure whose implementation is
complex for the purpose of guaranteeing a property that it
can't actually guarantee.
Will
More information about the R6RS
mailing list