Re: issue CONSTANT-CIRCULAR-COMPILATION, version 4

[Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>]

> The proposals below apply to COMPILE-FILE, since it must inherently
> copy structures.  If issue QUOTE-MAY-COPY is resolved in favor of
> allowing COMPILE and possibly EVAL to copy structures, the same
> constraints would also apply in those situations. 

Since these are not independent issues, I am not sure how to arrange
a fair vote.  My vote on either issue might depend on which version
of the other issue passed.  Is there a known procedure for dealing
with such problems?

> Proposal CONSTANT-CIRCULAR-COMPILATION:NO
> 
> State that it is an error for an object containing a circular reference to
> appear as a constant to be compiled.  State that the compiler is not
> required to preserve EQness of substructures.

Do you mean EQLness?

What does "preserve EQness" mean?  Does it mean things don't get less
EQ (copying), don't get more EQ (coalescing), or both?  I suspect it means
don't get less EQ, but see below.

> Proposal CONSTANT-CIRCULAR-COMPILATION:PRESERVE-SHARING-ONLY
> 
> State that it is an error for an object containing a circular
> reference to appear as a constant to be compiled.  State that the
> compiler is required to preserve EQness of substructures within a file
> compiled with COMPILE-FILE.
> 
>   Rationale:
> 
>   Disallowing portable programs from containing circular constants
>   allows compiled file loaders to use somewhat simpler implementation
>   strategies (for example, to build constants in a strict bottom-up
>   fashion).
> 
>   Some programs (such as PCL) have come to depend on COMPILE-FILE 
>   preserving the EQness of uninterned symbols, and it is cleaner
>   to requiring sharing to be preserved in general instead of making
       â?? require?
>   symbols be a special case.  Requiring sharing to be preserved still
>   allows loaders to build constants bottom-up.

> [...]

Symbols are always going to be a special case because after a dump and
load we can usually expect to get the same symbol back while we do not
expect this for conses.  And we often want uninterned symbols to be as
much as possible like other symbols except that they don't conflict
if their names happen to be the same.  Therefore, I think it is
reasonable to expect different things from uninterned symbols than
 from conses in file compilations.

It also seems to me that if symbols are supposed to stay EQ when they're
EQ they should also stay non-EQ when they're non-EQ.  Then, if we want 
symbols not to be a special case, conses also have to stay non-EQ when
they're not EQ, and we can't have coalescing.  So it again looks like
we might want symbols to be a special case.  But maybe not.  Maybe
coalescing is the problem.

I am still not sure we have a reasonable account of compilation and
constants that answers all of the different questions about copying,
coalescing, the implications for COMPILE and EVAL, etc. in a way that
makes sense.

> Current Practice:
> 
> A-Lisp preserves EQness of substructures (since it makes an effort to
> collapse isomorphic structures) but signals an error if an attempt is
> made to compile a circular constant.

Suppose I had an implementation that coalesced uninterned symbols that
had the same print name.  Would that be preserving EQness?

> Discussion:
> 
> JonL has argued against proposal CONSTANT-CIRCULAR-COMPILATION:NO, saying
> 
>   I don't see any performance justification; and even if there were, I'd
>   look at it with a very jaundiced eye, favoring interpreter/compiler
>   consistency over nickle-and-dime issues of compiler speed.

As far as circularities are concerned, we could just say they're
illegal in interpreted code too.  So I don't think this is an argument
against NO in particular.

Isn't that the way this consistency works in general: specify the
language so that only the file compilation semantics are guaranteed
anywhere?

Yours in confusion,
Jeff