🚀 go-pugleaf

re: Finalizations are quite useful and appropriate for a few very kinds of
    purposes.  Generally these involve explicit ``system programming''
    tasks such resource management for very large or otherwise expensive
    objects, or objects that require some active cleanup of non-Lisp
    resources, such as closing a Unix stream if inadvertently abandoned.
    . . . 

More of the beauty of a good Lisp implementation -- the lines between
Lisp-system programmer and end-application programmer are blurred.
A sophisticated Lisp user -- while not necessarily understanding every
thing about the Lisp implementation he is using -- will ultimately 
wind up needing many of the ``system programming'' facilities developed
by the Lisp implementor.  Such as RESOURCE's, Finalization, etc.


re: . . . 
    I don't think finalizations belong in the language standard -- they
    are a non-standard agreement between application writer and the
    implementation's storage management system.  

They are "a non-standard agreement ..." by historical accident -- not
by nature or by definition.


re: . . . It is still conceivable
    that memory architectures might someday change and someone might
    implement a lisp that doesn't need a gc because it can arbitrarily
    grow memory.  Although fanciful, such an implementation shouldn't be
    precluded, therefore the very concept of garbage itself doesn't belong
    anywhere in the language spec -- except tangentially with things like
    the DYNAMIC-EXTENT declaration.  It provides advice to the compiler
    and doesn't add any semantic content to the language.

See my paper in the 1980 Lisp conference: "Address/Memory Management
in a Gigantic Lisp Environment, or GC Considered Harmful."  The 
conference record has been reprinted by ACM, and this paper in
particular has been reproduced in an early issue of Lisp Pointers.


-- JonL --