🚀 go-pugleaf

> From: jeff@aiai.edinburgh.ac.uk (Jeff Dalton)
> 
> > 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.  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.
> >
> > Anyway, my advice is never to use finalizations for _computational_
> > effect.
> 
> That looks like good advice to me, but I disagree that finalization
> doesn't belong in the standard.  Very similar reasoning (IMHO) was
> used against FIXNUM declarations.  If the problem is that a certain
> desirable kind of implementation might be eliminated, then the
> relevant sections of the standard have to be phrased in such a
> way that such implementations are allowed.

The present standard doesn't even describe an interface to the garbage
collector itself -- such as the GC function in most implementations
that express the notion "I'd like gc to happen now rather than waiting
until it becomes necessary."  Indeed, I can't recollect that the spec
even mentions garbage collection anywhere.  Why would it?  Garbage
collection is not perceivable in the semantics of Common Lisp.  I
think you would need to specify a lot more standard interface to
memory management before you could focus on finalizations!

I think you're can't have it both ways: finalizations cannot be both a
good thing to avoid and a good thing to have in the standard.

The standard pretty much restricts itself to the behavior of programs
at the algorithmic level, not the performance and implementational
level.  (There are exceptions, of course, such as type and
dynamic-extent declarations.  These declarations are statements by the
programmer that values will remain within type/extent restrictions
stronger than those required by the base language semantics, with the
hope that the compiler may be able make optimizations.)  I still feel
the standard should restrict itself so much as possible to algorithmic
issues, and leave performance and resource management issues to
implementation extensions.

Your mention of the FIXNUM type declaration is illuminative.  As a
compiler writer, I have long felt that the FIXNUM declaration is
usually not appropriate in user-written code.  When a random
programmer writes the FIXNUM declaration, he usually means: "This
value will be an integer sufficiently small to be safely represented
by the FIXNUM data type."  But why is the programmer jumbling up his
"high-level" knowledge about the algorithic behavior of his program
with assumptions about the "low-level" representation that the program
should use?  Deciding on the mosty efficient data representation (in a
high level language) is the job of the compiler, not the programmer.

Furthermore, the FIXNUM declaration is just sloppily imprecise.  If
the programmer is really confident that a value will be in fixnum
range, it must be that he really knows its range of possible values.
If so, then it is unproductive to withhold any additional constraint
information from the compiler.  If the compler has been told only that
AGE is a FIXNUM, then it can't justifiably infer that (1+ AGE) or (*
AGE 12) are also FIXNUM.  But if the programmer tells the compiler
that AGE is, say, (INTEGER 0 150), then the compiler can infer that
each of those computed results are also FIXNUM.  The moral is that
algorithms should be defined in "algorithmic space" terms such as
(INTEGER low high) not "implementational space" terms such as FIXNUM.

The intention of my earlier message is that whatever place
finalizations might have in the communication between an application
and a lisp implementation, they are in "implementational space" not in
"algorithmic space."  I realize these domains are fuzzy and have
overlap, but (I believe) the separation is nonetheless an important
principle in software design.