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

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



On 06/06/2013 02:39 AM, Taylan Ulrich B. wrote:
> 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.)

I have the IEEE document.  In fact, I was the facilitator of that
working group.  IEEE1178 does not require eq? and eqv? to behave
the same on procedures.

I'd like to say this was by deliberate choice, but the fact is we
didn't discuss it much; procedures weren't on that list in the first
draft and nobody proposed adding them.  I think that if someone had
done so, I would most likely have responded by arguing in favor of
putting procedures on the list of types where eqv? and eq? are *not*
guaranteed to have equivalent behavior.

In my reading of the IEEE and R3RS through R4RS standards, it is a 
fairly uncontroversial choice to allow eq? to make a quick-comparison of 
pointers or location tags, while permitting eqv? at some computational 
cost to attempt to detect additional cases of equality.

'(at least conceptually) tagged with location codes' does not 
necessarily mean 'boxed.'  Indeed, I believe that's what the
'conceptually' business refers to; the location code need not
represent separate allocation.

> 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.)

I agree with this.

			Bear

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