Issue: CONSTANT-COMPILABLE-TYPES (Version 5)

[Jon L White <jonl@lucid.com>]

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

Obviously, the correct load-time behaviour cannot do anything which fails
to preserve EQness on these symbol references (your statement of the problem 
was that both tokens 'bar above, in the source file, access only one symbol).
However, since you said with malice aforethought that the necessary
package interrelations are different at load time than at compile time,
then in some sense we can reply with "the results are undefined".

I intend to reply more fully to moon's "amendment" to your
IN-PACKAGE-FUNCTIONALITY proposal; and in that reply, I will detail
why it is the case that compiling out symbols should *not* be
specified to be any of the following three simple algorithms:
   (1) fully-package qualified
   (2) just like PRINT
   (3) moon's minor variation on PRINT
That response will make it more clear why having two IN-PACKAGEs in a
single file ought to be allowable (although the Lucid documentation 
warns against it for reasons of style).  Anyone on this mailing list who 
doesn't receive cl-cleanup mail, but who would like to see this reply, 
should ask me privately for a copy.  The essense of this reply will
be that it is useful for an implementation to allow as many gratuitous
variations in the package setup between compile-time and load-time 
readings, provided that the source file does the same thing in each 
variation.



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

I very much agree with what you say here.  Unfortunately, not enough
people objected at the right time -- when the vote on 88-002R was being
taken -- and this "trojan horse" sneaked in to destroy the defstruct
house. [in fact, I wonder how many people actualy read 88-002R before
voting on it?]  It's possible that changing the default defstructs to be 
CLOS instances will make it smoother for PCL transition; but I don't see
how the incompatible changes to the :PRINT-FUNCTION, :COPIER, and 
EQUALP treatment on defstructs helps anyone.


    Date: Fri, 27 Jan 89 22:12 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    Subject: Re: Issue: CONSTANT-COMPILABLE-TYPES (Version 5)
    In-Reply-To: <8901251658.AA20469@defun.utah.edu>

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

See CLtL, p.81, second paragraph of the definition of EQUALP.  In the
context of 1984 CL, the phrase "objects which have components" clearly
includes defstruct instances.  It even explicitly mentions that you
can lose due to circularity, and that that's just too bad if you do.
By way of contrast, when defstruct instances were to be excluded from 
EQUAL, the phraseology used was "Certain objects that have components ..."
(see p.80),  and then an explicit listing of those "Certain objects" 
followed; the implication is clear that any type not directly mentioned
in that list is not to be descended by EQUAL.  

Thus EQUALP was intended to descend anything that had (pointer) 
components -- the only exception being symbols, which is explicitly
listed at the bottom of p.81  [I think it would have been acceptable 
to define symbols as not having "components"; but since that would
surely raise fruitless arguments with numerous persons, it was better
to make an explicit exception for symbols.]

Unfortunately, the EQUAL-STRUCTURE amendment that passed at the Hawaii
meeting retracted this very useful action of EQUALP on defstructs, and 
rendered it useless again.  Hopefully, the final version of the LOAD-
OBJECTS proposal will specify a more useful default behaviour (e.g., 
"just like the old CLtL behaviour"?), but note it this will have to 
amend the already-passed EQUAL-STRUCTURE proposal.


-- JonL --