[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue CONSTANT-CIRCULAR-COMPILATION, version 4
- To: firstname.lastname@example.org
- Subject: Re: issue CONSTANT-CIRCULAR-COMPILATION, version 4
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Tue, 24 Jan 89 16:28 EST
- Cc: CL-Compiler@SAIL.Stanford.EDU
- In-reply-to: <8901242109.AA19747@defun.utah.edu>
Date: Tue, 24 Jan 89 14:09:31 MST
From: email@example.com (Sandra J Loosemore)
> I do not think it's reasonable to make the language weaker than the
> source notation; and so I don't think *dump-circle* should exist
> at all: it should always be as if it were true.
Well, by this reasoning, *print-circle* shouldn't exist either. I
take it you would like to see another proposal added that requires the
compiler to correctly handle circularity and sharing all the time?
I'm somewhat sympathetic to the symmetry rule you're trying to apply here,
but I think the situations are not completely analogous. In particular,
*PRINT-CIRCLE* can reliably be controlled at runtime in a way that does not
induce frustration and porting headaches. That means it is reasonable to allow
users to control the expense the printer goes to in cases where they know
they have something simple.
On the other hand, we've taken deliberate steps to see that users can't really
control all aspects of compilation that they might like to in order to
accomodate a wide variety of compilation models. Further, the output of
compilation is not trivially inspectable to determine if it is "good enough".
One might argue that *PRINT-CIRCLE* should be required to be defaultly T
and people should be permitted to set it to NIL in circumstances where they
want to `optimize' the output of an expression known to be safe. A similar
argument is hard to make for *DUMP-CIRCLE* because you can't set it to NIL
and be sure you are not screwing some compiler or user-defined macro which
had set it to T for some reason.
Bugs due to *PRINT-CIRCLE* being set wrong may be annoying, but they're easily
spotted and easily fixed. With COMPILE, the effects could be a lot more
mysterious -- I could easily imagine all day marathon debugging sessions that
eventually turn up a bug like this.
As such, I concur with Jeff that you really need to just require it to work.
For as much as that could be a headache for some implementors, the benefits
to users of being able to depend on such a thing would be quite measurable.