On Fri, Nov 23, 2012 at 11:43 AM, Mark H Weaver <[email protected]> wrote:
> Alex Shinn <[email protected]> writes: > > > 2012/11/23 8:16 "Mark H Weaver" <[email protected]>: > >> > >> 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 the same value. > > Okay, so your point was that if the source code literally contains the > expression (eqv? 1.0 1.0), that the result is guaranteed to be #true? > Who cares? > With your proposed change (let ((x 1.0)) (eqv? x x)) would also be unspecified. > If the property you desire is to have any importance whatsoever, it must > hold in the more general case of (eqv? x 1.0), where 'x' is inexact and > numerically equal to 1.0. And my point is that you can't rely on that, > even with the current R7RS-draft-7 wording. 'eqv?' is simply the wrong > tool for that job. > > You already have a tool to do the job you need. It's called '='. > > For those of us to need reliable memoization, regardless of what numeric > representation is used, what tool shall we use? > I'm baffled. To you eqv? is so important you won't even use the standard if it's not specified the way you want, and yet at the same time you say the result doesn't matter? I really don't know what you want, and don't have time for this. -- Alex
_______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
