[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] [scheme-reports-wg1] Digest for scheme-reports-wg1@x - 13 Messages in 5 Topics
- To: Emmanuel Medernach <emmanuel.medernach@x>
- Subject: Re: [Scheme-reports] [scheme-reports-wg1] Digest for scheme-reports-wg1@x - 13 Messages in 5 Topics
- From: Alex Shinn <alexshinn@x>
- Date: Thu, 9 Aug 2012 16:12:36 +0900
- Cc: scheme-reports@x
- In-reply-to: <CAC_pKx-VYp48GBfUPUdD4bwxutr4B1r7Qw=EE2Ot5pGi_zi-EQ@mail.gmail.com>
- References: <email@example.com> <CA+U71=M7ke_4896SUTrq2avfdhseNf_P726mdLMUEDUV1WqUBw@mail.gmail.com> <CAC_pKx-VYp48GBfUPUdD4bwxutr4B1r7Qw=EE2Ot5pGi_zi-EQ@mail.gmail.com>
On Thu, Aug 9, 2012 at 4:08 PM, Emmanuel Medernach
> On Thu, Aug 9, 2012 at 4:18 AM, Noah Lavine <noah.b.lavine@x> wrote:
>> > Alex Shinn <alexshinn@x> 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.
> 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.
Scheme-reports mailing list