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 ? -- Emmanuel
_______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
