On Thu, Aug 9, 2012 at 4:08 PM, Emmanuel Medernach <[email protected]> wrote: > > On Thu, Aug 9, 2012 at 4:18 AM, Noah Lavine <[email protected]> wrote: >> >> Hello, >> >> > Alex Shinn <[email protected]> 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 [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
