[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue CONSTANT-CIRCULAR-COMPILATION, version 4
- To: email@example.com (Sandra J Loosemore)
- Subject: Re: issue CONSTANT-CIRCULAR-COMPILATION, version 4
- From: David N Gray <Gray@DSG.csc.ti.com>
- Date: Fri, 13 Jan 89 16:43:25 CST
- Cc: cperdue@Sun.COM (Cris Perdue), firstname.lastname@example.org
- In-reply-to: Msg of Tue, 10 Jan 89 11:26:23 MST from email@example.com (Sandra J Loosemore)
- Sender: GRAY@Kelvin.csc.ti.com
> I really dislike the idea of allowing it to be meaningful to tweak
> this variable on the fly during compilation.
But the analogy with *PRINT-CIRCLE* breaks down if you can't control it
where you need it. A program can do (LET ((*PRINT-CIRCLE* T)) ...) if
it knows it will be printing some circular lists, and similarly, a
program that uses circular constants should be able to declare that in
the program code itself. If this takes the form of "oh, by the way, you
have to manually set *DUMP-CIRCLE* before you can compile this file",
then the existence of such a flag becomes more of a booby trap than a
> In a
> multipass compiler, dumping of constants may not happen until much
> later than the processing of EVAL-WHEN forms. For example, you might
> not even look at constants until you've read in the code from the
> entire file and performed the required processing on top-level-forms.
Using the (EVAL-WHEN (COMPILE) (SETQ *DUMP-CIRCLE* T)) technique
shouldn't have any problem with this as long as you evaluate the SETQ
before you need to use *DUMP-CIRCLE* and leave it set for the remainder
> Plus, what happens if you try to coalesce a constant in created one
> place where *DUMP-CIRCLE* was true with one that was created in
> another place where *DUMP-CIRCLE* was false?
Assuming the compile-time evaluation happens in the first pass, then
subsequent passes will see the flag as being either true or false for
the entire file.