[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
In the discussion of our committee,
we wondered why the names of the functions for
gc, and exit to system
are NOT defined in CL.
I am only thinking of the interface naming, not the contents, like editor
interface is defined in CL but the editor subsystem is not defined yet.
I think the unified name for them can be defined in CL.
GC &optional parameters [function]
There are lots of names for the function to exit to system.
like, (bye) , (exit), (quit), ...
As an user and as a teacher, I feel happy if the name is only one for
The needs to define a unique name is for user convenience.
As to GC, it is not defined in CL too.
Of cause, there are several ways of GC techniques, and
there are several systems which do not have GC.
We discussed about the needs to define a unique name for it.
We found there are not so much needs, but for writing bench marking
If we might wanted to stick defining a name for GC, we might found
several situation which need a unique name for GC.
PS: attached is the mail from Scott Fahlman as a reply to my mail.
------------------ Comment for GC by Fahlman ---------------------------
Date: Sun, 08 Jun 1986 06:17:00 -0000
From: "Scott E. Fahlman" <Fahlman%C.CS.CMU.EDU@u-tokyo.junet>
Subject: User initiated GC ?
In-Reply-To: Msg of Fri 6 Jun 86 19:01:00+0900 from Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet at CSNET-RELAY.ARPA>
Received: from CSNet-Relay by utokyo-relay; 8 Jun 86 19:26:13-JST (Sun)
There is no explicit GC control in Common Lisp because we believed that
garbage collection would vary tremendously from one implementation to
another, and that new ideas for GC might come along in the future.
There are already systems that do mark-and-sweep GC, incremental copying
GC, stop-and-copy GC, reference-count GC with an occasional complete GC,
ephemeral GC (see Moon's paper in the last Lisp conference), and a
proposal by Jon White for a system that would have a huge memory and
would do a GC very rarely. Some systems do a GC because they are really
running out of space; others do a GC just to compact live items and
improve paging performance.
In such a diverse world, it is hard to imagine any use for explicit
GC-control functions that would not be system-dependent. One can
imagine a GC function that says "if the system ever stops to
garbage-collect, do it now", but when would you use this in portable
code? It might take a millisecond on one machine and six hours on
another. It might or might not guarantee that you're safe from further
GC's for a certain period.
So we decided to leave such controls to the discretion of the
implementor on any given system.
------------------- end ----------------------