[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Proposed language for 'eqv?' applied to inexact real numbers
John Cowan <cowan@x> writes:
> Mark H Weaver scripsit:
>> Anyway, there is a longstanding precedent for this "implementation can
>> prove" language in section 1.1. This text has not changed since the
>> All objects created in the course of a Scheme computation, including
>> procedures and continuations, have unlimited extent. No Scheme object
>> is ever destroyed. The reason that implementations of Scheme do not
>> (usually!) run out of storage is that they are permitted to reclaim
>> the storage occupied by an object if they can prove that the object
>> cannot possibly matter to any future computation.
>> You could just as easily say:
>> What is the operational definition of "can prove"? I say my
>> implementation can't prove anything about whether an object matters
>> to future computations, and then no memory will ever be freed.
> That's true, and indeed an implementation without GC is a conforming
> implementation. Early Lisp Machines worked that way: when you ran out
> of memory, you had to reboot, and memory-churning applications had to
> checkpoint their state to disk files.
Your concern could be addressed by adding the following text:
Implementations must be able to prove that two inexact real numbers
with the same internal representation are /operationally equivalent/.
However, it should be noted that it is generally unwise for programs to
depend upon 'eqv?' returning #true for inexact numbers. For example,
one cannot safely use 'case' to check for specific inexact numeric
values. This is already true for R7RS, since 'eqv?' (on IEEE 754-2008
representations) returns #false if the precisions or maximum exponents
do not match. 'eqv?' is simply the wrong tool for that job.
Scheme-reports mailing list