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 [email protected] 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 [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
