On Sun, Jun 9, 2013 at 9:51 PM, Taylan Ulrich B. <[email protected]>wrote:
> > I would constrain the returning-false condition via eqv?, indicating > that eqv? is always compatible and sometimes more capable: > > On symbols, booleans, the empty list, pairs, records, and non-empty > strings, vectors, and bytevectors, eq? and eqv? are guaranteed to > have the same behavior. On procedures eq? returns true if the > arguments' location tags are equal, and returns false at least when > eqv? also does. On numbers and characters, eq?'s behavior is > implementation-dependent, but it will always return either true or > false, and will return true only when eqv? would also return > true. On empty strings, empty vectors, and empty bytevectors, eq? > may also behave differently from eqv?. > Thanks, this sounds better. Assuming the WG does not choose to reverse our decision on requiring eq? and eqv? to behave the same on procedures (ballot item #467), then I think we'll use this text. BTW, for those interested, I checked the (chibi parse) test suite and the cost of using eqv? (via assv) for procedures instead of eq? was about a 2.8% slowdown (of the entire test suite, not a micro-benchmark). The difference between the two procedures in Chibi is especially large, but will be significant even in fast compilers because it's a difference between simple pointer comparison vs multiple branches and dereferencing memory you otherwise wouldn't need to. [And of course, the slowdown is for all practical purposes infinite if we can't use either eq? or eqv?.] -- Alex
_______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
