On Fri, Nov 23, 2012 at 8:16 AM, Mark H Weaver <[email protected]> wrote:
> Alex Shinn <[email protected]> writes: > > > On Fri, Nov 23, 2012 at 2:25 AM, Mark H Weaver <[email protected]> wrote: > > > > John Cowan <[email protected]> writes: > > > > > How about this compromise: simply remove the clause defining > > `eqv?` on > > > non-IEEE flonums? It is arguably not a proper domain for > > standardization > > > anyway, since there are no such implementations today. That > > would allow > > > future implementations to return `#t` or `#f` at their > > discretion. > > > > > > This would be *vastly* better than the current situation. If it's > > the > > best we can hope for, then _please_ do this. This would make it > > very > > likely that implementations would correctly extrapolate the > > definition > > of 'eqv?' to other representations. > > > > > > This has been mentioned multiple times, and I think > > would be vastly inferior to the current situation. It > > means that eqv? is basically unspecified on inexacts - > > you couldn't even rely on (eqv? 1.0 1.0) => #t. > > You already can't rely on that, even with the current R7RS wording. If > those two arguments are IEEE but of different precisions, then the > current R7RS definition requires that the result be #false. If one is > an IEEE number and the other is a non-IEEE inexact, then the current > definition fails to specify anything. > Read/write invariance ensures that 1.0 is always read as the same value. -- Alex
_______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
