Cleanup Issue ENCOURAGE NO SIDE-EFFECT GARBAGE
- Category
- ADDITION
- References
- CLtL
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.Aesthetics
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
Edit History
- Version 1, 20-Jul-88, Ginder