proposal: encourage no side-effect garbage

[trwrb!smpvax1!jrg@ucbvax.berkeley.edu]

Issue:         ENCOURAGE NO SIDE-EFFECT GARBAGE

References:    CLtL

Category:      ADDITION

Edit history:  Version 1, 20-Jul-88, Ginder

Problem description:

Many Common Lisp implementation create garbage as a side effect of
executing standard Common Lisp functions.  Under some circumstances,
this renders an Common Lisp "primitive" provided according to CLtL
unusable by applications under serious performance requirements or
virtual or physical memory space limitations.

Proposal:

Strongly encourage (not require) Common Lisp implementations to manage
internally-allocated storage in a manner so as not to generate garbage.
Explicitly point out that the quality of a Common Lisp implementation is
directly related to how well it solves this problem.

Rationale:

Some Common Lisp programmers need to write programs that react in
real-time to monitor physical processes or react to crisis situations.
It is imperative that some programs not be interrupted by a GC nor grow
so large by deferring GC that performance degrades.  It should be
possible to write programs with static memory requirements in Common
Lisp.

Current practice:

Programmers replace Common Lisp functions with private versions that
do not create garbage as necessary.

Cost to Users:

No cost, this is upward compatible.  (Users may get to throw away some
code, though!)

Cost of non-adoption:

Those programmers needing to avoid garbage creation can't or must
re-write parts of Common Lisp.

Benefits:

Unnecessary GC's will be avoided.  Common Lisp programs will work in a
more predictable manner.  Side-effect generation of garbage by an
implementation will become a more visible criterion for judging the
quality of an implementation.

Esthetics:

Neutral to vastly improved, depending on your orientation.  It is
extremely distasteful to me for a Common Lisp function to allocate more
storage than it returns to me as a value.



--Joe Ginder, Inference