change to instance structure protocol

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

re: [the point of the restriction from  p.13 of the July 30, 1990 
     metaobject protocol specification draft ??]

    I thought I had answered this before, perhaps not.  Think of this as the
    natural analog of the Lisp Symbol Redefinition issue.  It is trying to
    make the method definition you propose illegal, and it is doing it
    because that method is a "reserved word."  

[You may have discussed this before, in the time period between OOPSLA '90
and your November 15 deadline for AMOP Part I comments; if so, then I
probably didn't read all that mail in detail.]

OK, I see what you are getting at -- it isn't just to enable the kinds
of optimizations for which the MOONS-LOOPHOLE class is a "breaker".

However, "Lisp Symbol Redefinition" may not be the the best design against 
which to make an analogue.  I don't feel comfortable at all with it, for 
much the same reasons espoused earlier by Dick.  For example, I can't see 
any point at all to saying that the semantics of:

    (DEFSTRUCT POSITION . . . )

must be undefined, just because POSITION is in the COMMON-LISP package
(because of its functional value).  How, for example, does that help the 
end user any more than saying that he cannot portably do:

    (DEFSTRUCT USER::UPOSITION . . . )

??   There an always an implicit assumption that some other "portable" 
program might want to define a structure on USER::UPOSITION so should this 
symbol be off limits??  More precisely, adding cumbersome restrictions to 
the "Language" in order to accomplish a goal for which the package system 
was invented (i.e., end-user control over "imports" and "exports"), seems 
like a totally misdirected effort.  [Note that none of this bears on the
issue of forbidding a conforming implementation from making an extension
whereby COMMON-LISP:POSITION is given a defstruct definition.]


But AMOP Part II seems, to me,  to begin a much more fruitful approach
towards setting up a true "protocol" (namely, saying when and under what 
conditions such-and-such a definition is legal, and what it "means".)  I 
refer to the notions of "extending" and "overriding", and to the concept
of "interposed classes" and "promoted" methods for specified metaobjects.
Note that "extension" and "overriding", as "protocols", are not mechanically
checkable at definition time; but I don't see that as a problem.  I *would* 
see it as an stupid barrier if some implementation prevented me from defining 
an :AFTER method on ALLOCATE-INSTANCE for standard-objects simply because it 
is easy to implement that check.



-- JonL --