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.

--
John Cowan    cowan@ccil.org    http://ccil.org/~cowan
        Sound change operates regularly to produce irregularities;
        analogy operates irregularly to produce regularities.
                --E.H. Sturtevant, ca. 1945, probably at Yale

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