[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Scheme-reports] Formal Comment: R7RS 'eqv?' cannot be used for reliable memoization



On Fri, Nov 23, 2012 at 8:16 AM, Mark H Weaver <mhw@x> wrote:
Alex Shinn <alexshinn@x> writes:

> On Fri, Nov 23, 2012 at 2:25 AM, Mark H Weaver <mhw@x> wrote:
>
>     John Cowan <cowan@x> 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
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports