[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: Noah Lavine <noah.b.lavine@x>
- Subject: Re: [Scheme-reports] [scheme-reports-wg1] Digest for scheme-reports-wg1@x - 13 Messages in 5 Topics
- From: Emmanuel Medernach <emmanuel.medernach@x>
- Date: Thu, 9 Aug 2012 09:08:21 +0200
- Cc: scheme-reports@x
- In-reply-to: <CA+U71=M7ke_4896SUTrq2avfdhseNf_P726mdLMUEDUV1WqUBw@mail.gmail.com>
- References: <firstname.lastname@example.org> <CA+U71=M7ke_4896SUTrq2avfdhseNf_P726mdLMUEDUV1WqUBw@mail.gmail.com>
On Thu, Aug 9, 2012 at 4:18 AM, Noah Lavine <noah.b.lavine@x>
> 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
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 ?
Scheme-reports mailing list