🚀 go-pugleaf

    Date: Thu, 10 Sep 92 10:12:50 PDT
    From: jonl%kuwait@lucid.com (Jon L White)
        Date: Wed, 02 Sep 92 00:02:06 -0400
        From: Bob Kerns <rwk@crl.dec.com>
        . . . 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.
    
    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.
    
I can see how in some other contexts besides the one in my head,
this could be taken as saying "those nasty X3J13 folks screwed up."
I didn't mean to imply that X3J13 doesn't endorse good style, or
that I'm not part of the group I'm assigning the blame to.  We just
screwed up, because we didn't have enough foresight, and had to switch
horses in mid-stream.

My point was that from the user's point of view, the blame lies with us,
and not with any lack of style sense, understanding, or reasonable
expectations on the part of the user.  In other words, "Yes, this is a
kludge.  No, it's not your fault; it's reasonable to expect not to have
to kludge this way.  Don't change the way you think about how to use
this stuff."
    
    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.

Actually, I'm informally playing with another approach to this;
namely applying AMOP's principles to building a knowledge representation
system.  In KR terms, this becomes a meta-ontology, about how the KR
system works and is implemented.  I'm just trying to make building it
easier, and not seriously trying to design a meta-ontology with that as
a goal, but I do hope to understand how the MOP principles apply in this
area better when I'm done.

In a sense, AMOP represents the fruits of applying the historical search
for reflectivity in building representation systems, to the object world.
I think it's fitting for things to come full circle, and the results of
refining the AMOP back to reflective knowledge representation!