One goal of my definition was to specify what eqv? had to do in
implementations that might have extensions to R7RS. That is why I said
"the implementation cannot tell them apart". I was also hoping to
write a definition that would apply to all objects, not just numbers,
because it would say what eqv? is meant to do.

However, I would not claim that my definition got that right. Maybe
Emmanuel's is better, if it's worded like this:

Two objects are eqv? if either they are the same location (i.e. they
are eq?), or they are different locations but a) contain the same
value and b) could never be mutated to contain different values.

What do you think?

Noah

On Thu, Aug 9, 2012 at 3:12 AM, Alex Shinn <alexshinn@gmail.com> wrote:
> On Thu, Aug 9, 2012 at 4:08 PM, Emmanuel Medernach
> <emmanuel.medernach@gmail.com> wrote:
>>
>> On Thu, Aug 9, 2012 at 4:18 AM, Noah Lavine <noah.b.lavine@gmail.com> wrote:
>>>
>>> Hello,
>>>
>>> > Alex Shinn <alexshinn@gmail.com> Aug 07 12:18PM +0900 (on the WG1 list):
>>> >
>>> > I'm uncomfortable with the current result of same-bits
>>> > for #460.
>>> >
>>> > First, the definition is clumsy. What was a single rule
>>> > in R5RS and two rules in R6RS is now four rules, which
>>> > I fear may be difficult to remember.
>>> >
>>> > Second, the four rules do not extend naturally. We
>>> > had to add a special case for complex numbers, but
>>> > if an implementation, SRFI or later standard were to
>>> > add octernions or similar, their eqv? behavior would be
>>> > undefined. The R5RS and R6RS rules handle such
>>> > extensions in a forwards-compatible manner.
>>> >
>>> > Third, we're deferring to another standard which is
>>> > not and cannot be required, so the complexity is not
>>> > very meaningful. The motivation seems to involve
>>> > exposing +nan.0 payloads, but these are not
>>> > otherwise exposed by the standard, and are
>>> > implementation defined regardless. The R6RS
>>> > rationale explicitly notes this as a reason for making
>>> > NaN comparisons unspecified.
>>> >
>>> > Fourth, we're inventing here. To my knowledge
>>> > no Scheme currently implements eqv? in this way
>>> > (please correct me if I'm wrong).
>>> >
>>> > For all practical purposes the R6RS specification
>>> > is equivalent, more flexible, and simpler.
>>>
>>> I'd like to advocate for the "same-bits" definition of eqv? for a
>>> moment, because it matches my intuition very closely. I think that
>>> 'eqv?' as a predicate is supposed to be #t for things that "can't be
>>> told apart", for some reasonable definition of those words. The
>>> memoization idea captures this very well - if two things are eqv?,
>>> then they are equivalent for memoization purposes. This means that
>>> numbers with the same bits are always eqv?, but vectors with the same
>>> bits are not, because one of the vectors could have vector-set! called
>>> on it later.
>>>
>>> One way of expressing this is that two objects are eqv? if they are
>>> the same except for their location tags, and they contain no pointers
>>> to other objects (i.e. contain no other location tags that could be
>>> changed later).
>>>
>>> Another way might be that two objects are eqv? if, except for their
>>> location tags, the implementation cannot tell them apart.
>>> Implementations that allow users to link in arbitrary C functions will
>>> have to implement this as same-bits, but other implementations might
>>> do more strict comparisons.
>>
>>
>> +1
>>
>> Exactly, I think we could see eqv? as an equivalence predicate "up to
>> mutation". I mean if var1 and var2 are locations, (eqv? var1 var2) means
>> that any mutation of var1 is a mutation of var2. Do you agree with that ?
>> How would you word it more precisely ?
>
> The point is the (fixed) R6RS definition effectively specifies
> the same thing more generally and in simpler terms.
>
> --
> Alex

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