The solution is to run whatever clean up is needed, and just leave behind
the object which holds the handles to these resources. That object's storage
will be collected.

I hear "external resources", but "not Unix FDs", which are possibly
the most forgiving external resource I can think of.  So what would be
an external resource for which finalization would be appropriate?

What you can do with a finalizer is place an assertion in it which signals an
error if it finds the object to be other than cleaned up. Kind of like a
mortician checking for any signs of life before replacing the blood with
formaldehyde. ;)

  In my somewhat limited experience, it is not useful without "weak pointers",
  which are objects the weak pointers to which "vanish" when they are the only
  pointers that keep it alive for purposes of garbage collection and the object
  is therefore not kept alive, either.  Sometimes, you would want a system that
  uses weak hashtables for cached results of some sort, meaning that until the
  garbage collector runs, you can reference an object through a weak pointer,
  but if you have had no use for it at the time garbage collection occurs, it
  will effectively be tossed.  This is a very useful feature, but if you want
  to make the most of it, you might want some concomitant information that
  should be alive only when the object itself is alive, but which you would not
  want to tie together with a lot of pointers all over the place, because that
  would defeat the purpose of weak pointers.  Instead of letting things point
  to the weak object, you let them reference them indirectly and then let the
  weak object know.  When the weak object is tossed, it will know how to remove
  any indirect traces of itself with it, that would either not vanish on their
  own at all or which would need a test for whether their target had vanished.
  (Weak pointers magically turn to nil after garbage collection.)

  This may be very abstract and sound rather weird, but for a more intuitive
  example, think of human memory.  Forgetting is a rather important feature of
  human memory, which is extremely underrated.  Forgetting the conclusions when
  the observations are invalidated takes conscious effort in most people.  You
  find lots of people who "learn" something, then integrate that knowledge with
  something else and come up with a conclusion of some sort, which they tend to
  believe even after the first thing they learned turned out to be all wrong.
  It would be much better if the first thing you learned had a normal pointer
  to it on its own and weak pointers to the conclusions that were based upon it
  (because they should seamlessly vanish if invalidated, too), so that if you
  dropped the normal pointer, the finalization would know how to invalidate the
  conclusions based upon it as it went.  A simpler example is perhaps that you
  worked out a difficult probability problem a decade ago and then you remember
  that you solved it, but not what the solution was.  I may not be an old man,
  in fact I'm pretty sure I'm not, but working through old math textbooks can
  be a very humbling experience, to be repeated once very decade or so so you
  at least still know that your brain works, but the kind of ridiculous despair
  you may feel the first time in remembering that you solved it and trying so
  much harder to remember it than to work it out again, is probably very close
  what a Common Lisp program feels when it goes looking for the cached result
  of a three-second long computation and the weak pointer only goes "no".  On
  the flip side of Alzheimer's, there are many ways to get screwed if you
  remember something for too long, too.  Many Lisp programmers experience that
  the system behaves differently after a cold start because they forgot that
  they have done something the system had not forgotten along with their memory
  of having done it.  Emacs (Lisp) users sometimes have this problem, a useful
  keybinding that isn't, a mouse wheel that beeps or scrolls the wrong window,
  forgetting the last keyboard macro you used and thinking you invoked the
  previous one.  Such stuff.  The best expression of this problem was provided
  by an acquaintance of mine when his X server crashed and all remote sessions
  died, his multiple Emacsen croaked, his log output windows closed, and he was
  facing the standard X root window, all grey.  "My context!", he said quietly.
  Not that finalizers would have helped him.

  When I restrict the usefulness of finalization to weak pointers, it is
  because I strongly favor explicit cleanup for normal objects.  However, there
  is a whole world out there who do not.  The C++ crowd, for instance, have a
  moderately useful feature in that the destructors of stack-allocated objects
  are called when the stack is, for lack of a precise term, unwound.  (It is
  not, of course, unwound the way Common Lisp does it.)  If something like this
  is needed in Common Lisp, a competent Common Lisp programmer would simply
  design a new binding form that effectively calls the finalizer when you leave
  scope unless the object has been passed out of the scope in, say, a returned
  value.  Such a programming style could, for instance, be used with resources,
  where a "resource" is an object of a type that is picked off a pool of weak
  pointers to previousely deallocated objects when you need one (or a fresh
  object is allocated) and effectively returned to the pool when you exit
  scope.  The "finalization" would be to return it to the pool, but you would
  not do that if you were returning it.  Figuring out such lifetime thingies is
  computer work.  A similar stunt _could_ be used when dealing with streams:
  Suppose you close all streams upon scope exit that you have not returned to
  your caller as open streams.  You would want that stream to be closed when
  the caller just dropped it sometime later.  Note that the file descriptor in
  Unix is a resource of the above-mentioned kind and that the operating system
  has a finalization routine that is invoked upon exiting the program.  You
  would want similar precautions in a well-honed Common Lisp program.  Leaks
  are bad, and finalization may be used to ensure that you find them, but in
  order for leak detection to really work, you want to keep track of things
  that might leak with weak pointers.

In MACLISP, I have a vague recollection that the function
named "GCTWA" (a version of the function "GC") did something
with cleaning up file descriptors (our OS called then "channels").
But I think they had to first be explicitly closed with CLOSE
(which was not enough to GC them...some kind of intermediate resource?).  
I guess I have forgotten exactly what that was all about.

In a part of a C++ program that I wrote long ago, there was a master object
which held on to a collection of reference-counted subordinate objects.  It
owned a reference to each one of them. When the reference count dropped to 1,
it would remove the object from its collection and then drop the reference one
more time. A periodic timer callback, or perhaps it was a dedicated thread,
would sweep over the collection from time to time and perform this action. So
that's a kind of finalization mechanism.

Finalization cannot exist without a special object state distinct from
``garbage''. Java calls it ``finalizable'', with a further complication that a
finalizable object may hold references to others, which are not finalizable
independently of it, and so are in the ``finalizer-reachable'' state.

I can think of an instance when it would make sense to use finalizers
to close FDs, though.  Say you want to deal with data sets that can't
fit in your VM.  So you implement a class that's a proxy object that
you can use like an array (say), but which manages the retrieval of
the information from files itself.  To keep the illusion of these
objects being arrays, you don't want to have to call a destructor on
them by hand, because then your code needs to know which arrays are
arrays, and which are your proxy objects.  So you use finalization to
close the FDs the proxy object has open, possibly free memory in the C
heap, etc.  You can deal with the problem of keeping the number of FDs
bound, seperately: eg, keep a global pool of them for use by this
class, and allow them to steal them from one another, as needed.

Joel Ray Holveck <jo...@juniper.net> writes:

I wanted it to be as easy and natural for people to use 3D objects
they'd created as it was to use standard lisp data types.  E.g.,
something like this to create a window displaying a rendered sphere:

  (make-instance 'q3:qd3d-window
    :view-model (q3:create-sphere 0 0 0 1))

Or to create a group consisting of copies of the same sphere, with one
red and the other blue and translated:

  (let ((s (q3:create-sphere 0 0 0 1)))
    (q3:create-display-group
      (q3:create-attribute-set :diffuse-color 1 0 0)
      s
      (q3:translate-transform (q3:create-transform) 5 0 0)
      (q3:create-attribute-set :diffuse-color 0 0 1)
      s))

In particular I wanted to shield users from the reference counting
scheme that the underlying API used to manage the memory used by all
these objects, so I used MCL's finalization facility (MCL calls it
termination).  It worked extremely well and freed users from having to
deal with the details of memory management that often annoyed (me, at
least) when writing code in C that used this API.

There was one hitch, similar to one which Erik Naggum describes
running into in one of his postings: The 3D objects were allocated
from a different heap than lisp objects, so I sometimes ran out of
space in the 3D heap because lisp hadn't felt the need to GC.  In
practice, this happened very rarely.  And later, once 64 MB RAM became
a typical amount of memory for a workstation, it never happened again
to me.

The other thing I did was to also offer macros for making explicit
management of 3D object lifetime easy.  So if someone wanted to write
code like the examples above, they could (which was especially great
for explorative programming), but if they wanted to they could make
optimal use of the 3D heap by instead writing

  (q3:with-q3-objects
      ((s (q3:create-sphere 0 0 0 1))
       (red (q3:create-attribute-set :diffuse-color 1 0 0))
       (blue (q3:create-attribute-set :diffuse-color 0 0 1))
       (xform (q3:translate-transform (q3:create-transform) 5 0 0)))
    (q3:create-display-group red s xform blue s))

The with-q3-objects macro used unwind-protect cleanup forms that both
deallocated the 3D objects and cancelled finalization on them.

So i guess one possible answer to your question is something like
"when you are trying to make foreign data with fine granularity as
easy to use as native lisp data."  I was extremely happy that I had a
finalization facility for this use, and it certainly didn't feel at
all sloppy.  It let me do 3D graphics in a way that felt very lispy.