Re: [Scheme-reports] Procedural equivalence: the last debate

[taylanbayirli@x (Taylan Ulrich B.)]

will@x writes:

(From various e-mails.)

> I don't know how John Cowan inferred that eq? and eqv? behave
> exactly the same on procedures in R4RS/R5RS/IEEE Scheme.

> That history is why I can say with some authority that the R3RS,
> R4RS, IEEE, and R5RS standards do not require eq? and eqv? to
> behave the same on procedure arguments.

> [...] the R6RS requirement that eq? and eqv? behave the same on
> procedures, which was *not* required by the R5RS.

Actually, R5RS explicitly lists procedures as one of the types whose
behavior is guaranteed to be same for eq? and eqv?.  (R3RS and R4RS do
not; and I don't have the IEEE document.)

R3RS and R4RS:
http://people.csail.mit.edu/jaffer/r3rs_8.html#IDX197
http://people.csail.mit.edu/jaffer/r4rs_8.html#IDX217

R5RS:
http://people.csail.mit.edu/jaffer/r5rs_8.html#IDX199

I believe this must have been a mistake though, because it means that
either eqv? must be as primitive as eq? (i.e. it's prohibited from
detecting more sophisticated cases of operational equivalence), or eq?
must be as complex as eqv? (i.e. it cannot be implemented as pointer
comparison anymore), except if operationally equivalent procedures are
detected at compile-time already and made to be represented by the same
pointer, so eq? can be as smart as eqv? for procedures and still just be
a pointer comparison.  I see no reason for the standard to force this
specific strategy for that optimization though[1], when allowing eqv? to
be more capable than eq? would have allowed it to implement the same
sophisticated operational equivalence via different strategies while eq?
continues to be the mere object-identity test which we've always been
used to.

So far I find the R3RS/R4RS semantics the most obvious and intuitive,
where eq? and eqv? must both minimally detect procedures' identity, and
either is allowed to do more, but their behavior isn't needlessly
coupled to each other.  (Though it should probably be specified that eq?
may only return #t for procedures where eqv? also does, as is specified
for numbers and characters.)

On the other hand, seeing eq? as nothing more than a "dirty but more
efficient eqv?", and abandoning the notion of object-identity in favor
of operational equivalence, is entirely fine too in my opinion, if not
in fact more desirable.  So the question of whether eq? should work on
procedures is entirely a question of whether it is this that will result
in more efficiency gains, or the allowance of the delayed boxing
optimization for procedures (among possibly others).  (I understand that
your proposal does not prevent eq? from being implemented as an
efficient pointer comparison, but it prevents this efficient eq? from
being used in places where it will potentially receive a procedure
argument, so the question remains as to which will result in more total
efficiency gains in all plausible Scheme programs, which is why I still
say we should be careful before invalidating procedures for eq?.)

[1] Not to mention that it's entirely implicit as per the couple rules
scattered around, and not to mention that a standard is never expected
to force a specific implementation strategy when there are other valid
strategies to implement the same semantics.

Taylan

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