Issue CONSTANT-COMPILABLE-TYPES

[Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>]

The message that prompted this response was sent only to cl-compiler.  Since my
response touches on issues of more general interest, I've included cl-cleanup
and common-lisp-object-system as well.  Appologies in advance -- this turned
out to be a bit of a tirade. 

> Date: Tue, 31 Jan 89 05:05:58 PST
> From: Jon L White <jonl@lucid.com>
>
> > 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.
> 
> ...
> 
> 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 --

I wish to strongly disagree with almost everything said above.  There is a
fundamental assumption being made, namely that structures are second-class
citizens in the CLOS world.  This is most clearly expressed by the statement

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

This is terrible!  Awful!  Totally wrong!

Structures have certain restrictions (single inheritance, don't support
CHANGE-CLASS, ...) in exchange for potentially very efficient access.  When
deciding whether to implement a data structure using STRUCTURE-CLASS vs
STANDARD-CLASS, the question a programmer should be asking is "does this class
need multiple inheritance ...", not "am I ever going to need to dump one of
these things, or compare two of them using EQUALP, or ...".

Moon keeps pointing out that only the programmers who define/use a class can
know how to properly copy, dump, test for equality (whatever equality means),
&etc.  Unfortunately, under strong pressure from some people he occasionally
sounds like he is willing to cave in on this point in the case of structures.
Well I won't.  Removing structure objects from these kinds of protocols and
instead giving them trivial component-wise functionality is utter nonsense.  By
all means we should give the programmer mechanisms to help him specify that
kind of behavior if that is what he wants.  But it must be a concious decision,
not a default behavior!  (As an aside, if it were up to me, the default copier
option for defstruct would be Nil.)

With regard to the EQUAL-STRUCTURE amendment that passed at the Hawaii meeting,
I insisted on EQ for structures because I firmly believe that is the right
default.  I would still like to see a proposal to make EQUALP a generic
function; unfortunately, the group who said they would make such a proposal
have not done so.  I was thinking about making such a proposal myself, but I've
been having trouble with the specification of the hash function, due to some
ideas I've been working on with regard to hash-table implementations.

kab
-------