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