[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue CONSTANT-CIRCULAR-COMPILATION, version 4
- To: sandra <@cs.utah.edu:sandra@defun>, email@example.com
- Subject: Re: issue CONSTANT-CIRCULAR-COMPILATION, version 4
- From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
- Date: Wed, 25 Jan 89 17:07:36 GMT
- Cc: David N Gray <@NSS.Cs.Ucl.AC.UK:Gray@dsg.csc.ti.com>, Cris Perdue <firstname.lastname@example.org>
> > 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.
My reasoning has nothing to do with *print-circle*. Compilation is
supposed to preserve the semantics of the language; PRINT is supposed
to print data objects so that they can be read back in by READ.
If the source code contains a constant, we have to say what
that means. We know the source code can be a list structure,
so we can say what the constant means in terms of that structure.
We can say it means "an equivalent object", where "equivalent"
is defined in some way. And, yes, we might rule out circularities.
But I think we should respect what the user can write as text source
even if the greater power of list-structure source is more than
we can handle. [and #. is an exception, I suppose.]
> I take it you would like to see another proposal added that requires the
> compiler to correctly handle circularity and sharing all the time?
What I'd like is for us to think about what we want compilation to
do first and let that drive the implementational details. I'm afraid
that we're letting the mechanics of compilation and interpretation
and fasloading distract us from semantics. The semantics must be
constrained by what we can reasonably implement, but we should try
to make them as consistent and uncluttered as we can.
I do not think implementation-oriented switches that change the
semantics are a good idea. If circular structures are something we
can handle, we should handle them. If not, we shouldn't. In neither
case should we have a switch. If the implementation cost is so high
that we feel we want to switch it off much of the time, we should
just not promise to handle circularities at all (in file compilation
I do not think of *print-circle* as smething that changes the
semantics of constants. It just changes the actions of PRINT.