[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: JAR@mc.lcs.mit.edu*Subject*: Re: EQ?, again*From*: willc%tekchips%tektronix.csnet@CSNET-RELAY.ARPA*Date*: 21 Feb 86 11:12:30 PST (Fri)*Cc*: RRRS-AUTHORS@mc.lcs.mit.edu*Comment*: Message received over unauthenticated port at tektronix*In-Reply-To*: Your message of Wed, 19 Feb 86 21:37:49 EST., <[MC.LCS.MIT.EDU].823678.860219.JAR>

Executive summary: 1-I 2-E 3-I 4-E 5-I 6-X (i.e., the straight Jonathan party ticket) I 1. (EQ? (LAMBDA (X) X) (LAMBDA (Y) Y)) ;"Coalescing" E 2. (EQV? (LAMBDA (X) X) (LAMBDA (Y) Y)) I 3. (LET ((X (LAMBDA (Z) Z))) (EQ? X X)) ;"Splitting" E 4. (LET ((X (LAMBDA (Z) Z))) (EQV? X X)) I 5. (LET ((X ... any expression evaluating to an exact number ...)) (EQ? X X)) X 6. (EQ? #\X #\X) Notes: Re example 2, Kent Pitman writes: I think it important to say that EQV? cannot return false when EQ? has returned true. This would make EQV? implementation-dependent, just like EQ?. If EQV? of two procedures is an error, however, then it would be fair to have an implementation note suggesting that if EQV? does not actually report an error when applied to procedures, it should return whatever EQ? returns. Such a note would not be part of the semantics of EQV?, because there is no way anyone could rely on it to write implementation-independent code. Re example 5, I nearly said I didn't care. The main reason I care is that I think a T vote for example 5 should imply a T vote for (LET ((X ... any expression evaluating to an exact number ...)) (EQ? X (1+ (-1+ X)))) and I suspect that people who vote T on example 5 won't agree. Peace, Will

**References**:**EQ?, again***From:*Jonathan A Rees <JAR@MC.LCS.MIT.EDU>

- Prev by Date:
**Re: survey - JAR's answers** - Next by Date:
**EQ?, again** - Prev by thread:
**EQ?, again** - Next by thread:
**EQ?, again** - Index(es):