🚀 go-pugleaf

re: This registration is easy to do with make-instance/initialize-instance,
    but any such registration procedure has the problem that
    registration/deregistration pairs are an unending source of errors in
    C programs that use malloc/free.   The problem is similar. The problem
    with  a destructor is that it is unclear when a "standard"
    destructor/finalizer should operate.

One of the reasons I sent such a lengthy reply to the original message
was to alert readers to the danger of thinking that "finalization" and
"destructoring" were one and the same.  Indeed, as you point out, a major
source of insidious errors in C programs can be the premature destruction
of non-"dead" data.   However, the basic problem is NOT the pairing of
"registration/deregistration" actions [your term], but rather the inability
of the C programmer ever to be assured that some data structure beyond his
immediate control isn't referencing the "dead-meat" datum.  The beauty of GC
is that "pairing" can be maintained accurately and automatically.


re: Are explicit make/destroy pairs (with all
    their problems) the best we can do in general?

No.  Explicit, paired make/destroy actions can be done in any primitive
language (even FORTRAN?).  But languages with pre-existing automated memory
management -- such as the Lisp family, SmallTalk, APL, and a handful of
others -- can *offer* one bit of information to the destructor client that
wouldn't otherwise easily be  obtainable, namely that no other program data
structure references this object.  That is the essence of "finalization."



-- JonL --