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

[Mark H Weaver <mhw@x>]

Alex Shinn <alexshinn@x> writes:
> With your proposed change (let ((x 1.0)) (eqv? x x)) would
> also be unspecified.

I would prefer for that to be #true, and under my proposal it would be
#true as long as the implementation can prove that x is operationally
equivalent to itself.

If you're worried that an implementation can't prove that, then you
should also worry about running out of memory, since Scheme makes no
guarantee that memory will ever be reclaimed.  It merely _permits_ an
implementation to reclaim memory if it can prove that it's safe to do
so.

Anyway, in response to John Cowan's concerns about this issue, I added
another sentence requiring that implementations must be able to prove
that two inexact numbers with the same internal representation are
operationally equivalent.

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

All of the examples you have given are cases where 'eqv?' is the wrong
tool for the job, and where it _already_ fails to do the job you need.
'=' is the appropriate tool for those cases.

Why do you need two primitives to do the job you need, leaving me with
none to do the job I need?

> I really don't know what you want, and don't have time for this.

As I wrote in the first message of this thread, the minimum requirement
for memoization is that if two objects are _not_ operationally
equivalent, then 'eqv?' must return #false.  If that requirement is
violated, then memoized procedures will sometimes return the wrong
answers.

It is also preferable that if two objects _are_ operationally
equivalent, then 'eqv?' should return #true, but that's just gravy.  If
this is violated, then memoized procedures will sometimes do unnecessary
work and accumulate redundant entries in the table.

As it is now, the non-IEEE clauses of R7RS-draft-7 _require_ that the
above hard requirement is violated, thus making reliable memoization
impossible.

As a compromise, I could live with having the non-IEEE cases left
unspecified.  It's quite likely that implementors would understand how
to correctly extrapolate the "same bits" idea (expressed in the IEEE
clauses) to new representations.

The current draft requires that they extrapolate incorrectly, which is
far worse than saying nothing at all.

      Mark

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports