[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
issue CONSTANT-CIRCULAR-COMPILATION, version 4
- To: sandra%defun@cs.utah.edu
- Subject: issue CONSTANT-CIRCULAR-COMPILATION, version 4
- From: Jim McDonald <jlm@lucid.com>
- Date: Thu, 26 Jan 89 12:16:11 PST
- Cc: cperdue@Sun.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM, cl-compiler@sail.stanford.edu, jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
- In-reply-to: Sandra J Loosemore's message of Thu, 26 Jan 89 11:25:30 MST <8901261825.AA21425@defun.utah.edu>
I agree with Sandra. If COMPILE-FILE is required to handle
circularities in some cases, then it is not worth worrying about the
marginal speed improvements that might be obtained by declarations of
(non-)circularity.
(A) Jonl may correct me, but I think the experience at Lucid has
been that the overhead per constant for detecting circularities
is minor, perhaps down in the noise.
(B) Circular data is rare.
(C) Time spent compiling code (as opposed to running it) is rarely
critical.
The pain involved in handling circular data is felt almost entirely by
the person who writes and debugs the faslout code. (The basic ideas
are simple, but given the wealth of data types in common lisp, there
are a lot of special cases, each of which can potentially be miscoded.)
Nonetheless, there are existance proofs that people survive the
experience and that robust code emerges.
I think any serious implementation of COMPILE-FILE will quietly handle
circular data, just as any serious garbage collector is expected to.
jlm