It was pointed out that my counter to Will's proposal may
not have been clear.
I propose we restore the semantics of eqv? and eq? on
procedures to IEEE/R5RS as the WG had intended.
From this we make only one change, which is what the
WG voted on in ballot item #467, which is that eqv? may
make a broader distinction than eq?. However, this is
in the context of retaining the R5RS semantics for eq?
on procedures, so effectively we will duplicate the
same semantics for eqv? and eq? on procedures.
The change is largely ideological, and would make it
easier should a future standard wish to make eq?
unspecified on procedures. It would only break R5RS
programs in very pathological cases, and only in
implementations which as yet do not exist.
Unfortunately, not using eqv? to define eq? on
procedures becomes clumsy. A potential specification
is as follows, though I'm open to suggestions for
improvement:
----
The eqv? procedure returns #t if:
* obj1 and obj2 are procedures whose location tags are
equal (section 4.1.4).
The eqv? procedure returns #f if
* obj1 and obj2 are procedures that would behave
differently (return different values or have different side
effects) for some arguments.
...
On symbols, booleans, the empty list, pairs, records, and
non-empty strings, vectors, and bytevectors, eq? and eqv? are
guaranteed to have the same behavior. On procedures eq? returns
true if the arguments' location tags are equal, and returns false
if the arguments would behave differently for some arguments. On
numbers and characters, eq?'s behavior is
implementation-dependent, but it will always return either true
or false, and will return true only when eqv? would also return
true. On empty strings, empty vectors, and empty bytevectors, eq?
may also behave differently from eqv?.
syntax to specify various standard optimizations.
to provide R6RS-style safety guarantees. Among the
to be unspecified on procedures.