Re: issue CONSTANT-CIRCULAR-COMPILATION, version 4

[David N Gray <Gray@DSG.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
feature.

>    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
of compilation.

> 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.