Issue: CONSTANT-COMPILABLE-TYPES (Version 5)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

Good try but needs amendments.

I think this suffers from fundamental confusion between three distinct
concepts:
   (1) relation of objects in the input of COMPILE-FILE to corresponding
   objects in the result of LOAD of the output of COMPILE-FILE.
   (2) relation of two objects in the output of a single COMPILE-FILE.
   (3) relation of two objects in the output of two different COMPILE-FILEs.
All of these are important, but the answers are different.  I think they
all have to be dealt with within one proposal, but the writeup for each
datatype should be conscious of each of the three issues.

I'm not going to try to evaluate the parenthesized remark about
cross-compilers under numbers and characters, other than to say that
this is a reflection of the same fundamental confusion.  The test for
similarity as constants cannot ever really be EQL, since it is
impossible to bring the source and the product together into the same
Lisp to hand them as arguments to the same call to the EQL function.
You mean "something like EQL."  I don't know a good way to say this
precisely, even though I think everyone knows what you mean.  Or could
you define it in terms of loading the compiler's output file back into
the same Lisp it was compiled in?  Does that work in all
implementations?  It sure doesn't work in cross-compilers.

The part about uninterned symbols is inconsistent.  Are they compared by
name, as it says in one place, or by EQ, as it says in another?

Also interned symbols accessible in the value of *PACKAGE* at compile
time should map into interned symbols accessible in the value of
*PACKAGE* at load time, rather than the stricter requirement that the
home package be the same.  This allows some flexibility to deal with
minor redefinitions of packages.  It's also current practice in any
implementation where the compiler/loader work like print/read and
only use a package prefix if the symbol is not accessible.

Arrays: saying that ARRAY-ELEMENT-TYPE has to be equal for arrays of all
ranks -except- 1 is crazy.  As far as I can tell what you're trying to
accomplish is to make arrays of rank 1 (only) respect the fill-pointer.
That's fine, but except for the fill-pointer all ranks should be
consistent.  ARRAY-ELEMENT-TYPE should have to be equal (actually,
EQUAL-TYPEP, a function missing from Common Lisp, which can be defined
in terms of two calls to SUBTYPEP in the obvious way).

Saying the compiler may not produce an adjustable array from a
non-adjustable array can be unimplementable for cross-compilers.  I
think what you're actually trying to say is that if the input is of type
SIMPLE-ARRAY, the output must be, while at the same time it's valid for
the output to be of type SIMPLE-ARRAY even if the input is not.  I agree
with it when it's said that way.  I think if you simply say those words,
combined with listing the array attributes that are preserved, you'll
come out where you want to be.

I believe it's wrong for structures to be compared by component equality,
rather than by EQ.  It is surely wrong for standard-class instances.
The LOAD-OBJECTS cleanup proposal can cover this for both structures
and standard-class instances; two of these are similar as constants
if they are EQ or if the MAKE-LOAD-FORMS method produces a form
that produces objects that are EQ.  For generic functions and methods,
the comparison function is EQ and the reconstruction function is
defined by a MAKE-LOAD-FORMS method essentially coming from the
metaobject protocol.

Similarity for hash tables can just be EQUALP, now that JonL's amendment
to EQUAL-STRUCTURE has passed.  No, that's wrong, it uses the wrong
function to compare the values.  But you can make a reference to EQUALP
to help explain the algorithm.

Readtables probably can't work since most functions aren't allowed, and
readtables contain functions.

Everything this says about functions strikes me as confused, but I
haven't thought about it very hard.

I'd look to look at this whole proposal again harder when you have
a revised version.

Symbolics Genera current practice: aside from some current bugs we
have with circular structures of certain types and with preserving
the identity of CONSes under EQ, this is more or less consistent
with our current practice, if you made the changes implied by my
earlier comments.  We preserve the :displaced-to and :fill-pointer
array attributes.  I doubt that we do what the proposal says for
hash-tables, readtables, and random-states.  We support dumping
compiled and interpreted functions, but not closures, which in
effect means we don't support dumping functions.