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

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

    Date: Wed, 25 Jan 89 09:58:52 MST
    From: 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?

UNinterned symbols.  UN, UN, UN.  UN.

    ....My own
    feeling is that no valid program ought to have the package environment
    defined inconsistently between compile and load time in [deleted] manner,
    and we shouldn't waste our time trying to specify what happens if it
    is.

I agree, and said so in some other mail sent earlier this evening on
IN-PACKAGE-FUNCTIONALITY.

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

Incompatible?  Please point to the place in CLtL that says that similarity
as constants is defined for structures by component equality.  For that
matter, point to any place in CLtL that says anything about componentwise
comparison of structures.

In any case, the LOAD-OBJECTS proposal can propose whichever default
behavior for structures the people amending it and voting on it prefer.

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

I do.  Better not to require something that we might understand in the
future, than to require something that we will later discover is screwed
up.

UN.  <:-)