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

Alex Shinn <alexshinn@x> writes:

> 2012/11/23 8:16 "Mark H Weaver" <mhw@x>:
>>

>> 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 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