w...@ccs.neu.edu scripsit:
> > I'm not sure I understand this. If two objects (not of primitive type)
> > are ==, they are necessarily also equals(), but of course not vice versa.
> > The general contract for equals() guarantees the first part, and good
> > implementation technique is for the first statement of equals(Object that)
> > in any class to be "if (this == that) return true;".
>
> Yes, and that's precisely the guarantee that should have been
> made by the Scheme standards.
I think the comparison is bad, because Java `equals()` is much more like
Scheme `equal?`, only extensible. There is no real Java equivalent
of `eqv?`, because boxed numbers and characters must be compared with
`equals()`.
> Instead, the R5RS and R6RS went beyond that guarantee by overspecifying:
> Both the R5RS and R6RS insist that eq? and eqv? "have the same behavior"
> on procedures, i.e.
>
> (eq? proc1 proc2) if and only if (eqv? proc1 proc2).
>
> That overspecification was a mistake. I hope it will be fixed
> in some future standard for Scheme.
Funny you should say that. I just added ticket #467 as a late-breaking
item on the current ballot. Here's the text:
This proposal stems from ​remarks by Alaric Snell-Pym and Will
Clinger on the r6rs public mailing list. If eq? is allowed to
return #f on two procedures when eqv? nevertheless returns #t, as is
already the case for numbers and characters, then more intelligent
implementation-specific procedure comparisons using eqv? are possible,
while still keeping eq? simple enough to inline easily.
--
I now introduce Professor Smullyan, John Cowan
who will prove to you that either co...@ccil.org
he doesn't exist or you don't exist, http://www.ccil.org/~cowan
but you won't know which. --Melvin Fitting
_______________________________________________
r6rs-discuss mailing list
r6rs-discuss@lists.r6rs.org
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
