🚀 go-pugleaf

[please accept my apologies if you get this msg more than once -- that may 
be the price you have to pay for being an "email news hound"]

There is a common thread to several questions raised on the two separate
email lists a week or so ago; the original Subject lines were:

 1.  specifying the type of a slot in a defclass (general commonlisp question)
 2.  At the boundary of the MOP?
 3.  Alternative specializer types

so I'm taking the liberty of replying to these questions with a sort of 
combined comment.


re: Subject: Re: specifying the type of a slot in a defclass (general
	     commonlisp question) 
    Date: Wed, 02 Sep 92 00:02:06 -0400
    From: Bob Kerns <rwk@crl.dec.com>
    . . . 
    (macrolet ((define-my-defclass ()
		 `(defclass foo () ((slot :type (member ,foo ,bar ,quux))))))
      (define-my-defclass))

    . . . the blame falls squarely on X3J13 for not including a 
    programatic equivalent to DEFCLASS.  This violates one of my prime 
    macro style rule, which is that there should always be a way to do
    the work of a macro programatically.


As Lisp is a (mostly) "functional programming language", one ought to 
expect there to be a functional interface to *everything* that is 
doable by the end user.  This would include operations whose documented 
interface is a macro (such as DEFUN, DEFCLASS, etc, but *not* language 
syntax such as QUOTE, IF, BLOCK, etc); also,it would include actions 
initiated by keyboard or mouse activity, asynchronous interrupts, etc.

Such a "programmatic interface" principle was at the heart of the
Interlisp environment years and years ago.

On the other hand, I would not hold X3J13 so culpable of "principal 
violation" here -- as I recall, we ("what you mean 'we', White Man?")
relegated the "programmatic interface" for class creation to the 
Metaobject Protocol chapter -- the infamous "Chapter 3."  Little did 
we realize back then (in June 1988 and January 1989) how open-ended a 
task it would become to specify and to agree upon a fuller Metaobject 
Protocol.

The bright side is that subsets of some metaobject protocols are in 
fact becoming de facto standards.  Symbolics and Lucid (with consent 
from Franz too, I believe) subscribed to a limited "de facto" standard 
back in March 1990, which consisted of a few classes and functions 
going beyond the pale of CLtL2.  This subset was specifically for the 
purpose of being able to do introspection into the obvious (and 
necessary) metaobjects such as CLASS, SLOT-DEFINITION, METHOD, and 
GENERIC-FUNCTION.  And this subset is in fact a subset of what was 
finally to appear in AMOP a year or so later (with maybe one or two 
exceptions of some "old" stuff that got dropped from AMOP)

Additionally, another part of the emerging metaobject protocols
proposals is, I believe, becoming a de facto standard -- namely the 
creative part for metaobjects.  This is to say that the functional 
interface for DEFCLASS (among others) is being accepted from AMOP;  
that ENSURE-CLASS is being implemented by the various vendors, and 
that class object creations are primarily a call to MAKE-INSTANCE 
with the appropriate initargs.  The documentation for the initargs 
for initialization of the several metaobject classes is being 
accepted from AMOP.  (We may partly thank the CLIM effort for this, 
as it pushed the boundaries of what was merely documented in CLTL2; 
and those vendors supporting CLIM had to accommodate to the style of 
CLOS usage therein.)

Also, to a degree, AMOP's SLOT-VALUE protocol is being accepted, but 
there were some last-minute changes in it -- the proposal part differs 
in some critical aspects from the sample implementation part.

I do have serious reservations about some other parts of AMOP, mostly
because the line between "metaobject proposal" and "demonstration of 
a working subset of CLOS (i.e., CLOSETTE)" is not all that well drawn. 
The items left out of the subset -- such as method combination, argument
precedence order, and other critical parts -- leave a deceptively simple
approach to effective method computation and generic-function dispatch. 
I am not saying that the approach is unworkable, but rather that it is 
not yet proven in the same way as the "introspective", "creative", and
SLOT-VALUE parts mentioned above.  The "proof" involves not only the 
utility of the interfaces, but also the reasonableness of an efficient 
implementation for them.



re: To: comp.lang.clos@cis.ohio-state.edu
    Date: Tue,  1 Sep 92 15:04:29 PDT
    From: Thomas_E_Morgan@cup.portal.com
    Subject: At the boundary of the MOP?
    . . .
    Am I beyond the pale here?  This question has also made me 
    curious about exactly where the limits of the MOP design are, 
    and how those limits might be described. 

Of course, this is a much broader issue than the topic that apparently 
motivated your question -- namely how to "take over" the slot storage 
on a per-metaclass basis.  That one should be able to do this is a 
fundamental goal of CLOS and strikes at the very reason why metaclasses 
and metaobject protocols are part of this language.  For examples of 
such "taking over", you might find such in one of the columns in AI 
Expert by Nick Bourbaki (also you could enroll in the advanced CLOS 
tutorial I have been giving at the OOPSLA and LUV conferences, as this 
is one of my prime examples of the value of such CLOS protocols.)

On the other hand, the questions you raised about the interactions of 
such "taking over" with the existing instance initialization protocol
shows that AMOP is more like a specification turning into a protocol
than a complete "protocol" itself.  For a "metaclass protocol", one 
would expect a complete description of the kinds of interactions that 
could occur, along with prescriptions for "how to do it"; but as I 
mentioned above, this may be a rather open-ended quest.  [And yet, 
for the limited queston of interactions with SHARED-INITIALIZE, the 
"protocol" should be relatively simple, no?]



re: Date: 8 Sep 92 01:09:40 GMT
    From: lange@lanai.cs.ucla.edu (Trent Lange)
    Subject: Alternative specializer types
    . . . 
    (defmethod foo ((self (and class1-mixin class2-mixin))) ...)


As Danny Bobrow's reply indicated, there are some theoretically very
interesting directions in which generic-function discrimination can
be extended, including boolean combinations of classes.  However,
research into the style suggested by these directions would probably
have to make some more basic alterations to a Lisp/CLOS system than
are envisioned in AMOP's published interfaces.



-- JonL --