Re: Issue: CONSTANT-COMPILABLE-TYPES (Version 5)

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

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

I don't see the inconsistency.  If two symbols in a single Common Lisp
"address space" have the same name and are interned in the same home
package, they *must* be EQ, right?

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

This could cause some interesting problems if the value of *PACKAGE*
changes throughout the file.  Note that neither CLtL nor my revised
proposal on issue IN-PACKAGE-FUNCTIONALITY forbid this from happening.
(CLtL merely -suggests- putting the call to IN-PACKAGE at the top of
the file, "as a matter of style").  Suppose that at compile-time,
symbol BAR is accessible in both packages P1 and P2 (but its home
package is somewhere else), and at load-time it's not. 

    (in-package :p1)
    ... 'bar ...
    (in-package :p2)
    ... 'bar ...

Would the correct load-time behavior for this example be to create two
different, non-EQ symbols named BAR, one in each of packages P1 and
P2?  That would violate the principle that symbols within a single
file that are EQ at compile time must also be EQ at load time.  My own
feeling is that no valid program ought to have the package environment
defined inconsistently between compile and load time in this manner,
and we shouldn't waste our time trying to specify what happens if it
is.

> Arrays: saying that ARRAY-ELEMENT-TYPE has to be equal for arrays of all
> ranks -except- 1 is crazy.  

You're right, this was probably an oversight.

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

I disagree with the idea of changing the handling for structures.  
Introducing the LOAD-OBJECTS protocol for standard-class instances is fine,
but structures have been part of the language for a while already and I
don't see any need to change their handling in an incompatible way.  If
people find that the default handling of structures is not sufficient for
their needs, that's probably a sign that they really need to use the more
complex protocol for standard-class objects instead.

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

It strikes me as confused, too.  I've been arguing for simply not requiring
functions to be dumpable at all, but not everybody agrees with me.

-Sandra
-------