John Cowan <cowan@mercury.ccil.org> 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
>> RRRS:
>>
>>    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.

     Mark

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