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

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

> UNinterned symbols.  UN, UN, UN.  UN.

Oops, my oversight -- I must have been asleep.  There -is- a rationale
for the apparent inconsistency, which is that -any- two symbols which
are EQ in the source file ought to also be EQ when the compiled file
is loaded.  (It was noted that PCL depends on this behavior and some
implementations that didn't behave this way before were "fixed" in
order to accomodate PCL.) I think it would be even more inconsistent
if uninterned symbols behaved differently than interned symbols in
this regard. 

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

The question here is not comparison of structures, but how
COMPILE-FILE/LOAD produces an equivalent copy of the original
structure.  Every Lisp I have ever used dumps them by components.
And, I presume the copier function defined by DEFSTRUCT also copies
structures by components.  To me, it not only seems unnecessary to
burden structures with so much extra protocol, it also seems
inconsistent to make the protocol only apply to copying performed by
COMPILE-FILE/LOAD, and not to the default copier function. 

-Sandra
-------