[Jeff Morrill: MOP hacks]

[kanderso@DINO.BBN.COM]

I asked some of our slot hackers to describe their experience to
support this discussion.  This is a response from Jeff Morrill.  Tom
Reinhardt also has some interesting experience with this, and
described some of it in detail at a CLOS workshop at OPSLA 1989.

k
------- Forwarded Message

Date: Fri, 2 Nov 90 13:33 EST
From: Jeff Morrill <jmorrill@BBN.COM>
Subject: MOP hacks
To: kanderson@BBN.COM
cc: jmorrill@BBN.COM, delatizky@BBN.COM, treinhardt@BBN.COM
Message-ID: <19901102183324.2.JMORRILL@adams.bbn.com>

Ken,

You asked for a description of what I have done with the mop.  Here are the highlights.

1.  Definition of SLOT-FILLER-MIXIN, a metaclass.

In my expert system, a "slot-value" is really a structure containing (1) the
"real" value, and (2) a pointer to the RULE responsible for inferring that
value (used to construct explanations).  Once uncertainty is supported, I
should like to include a DISTRIBUTION OF BELIEF as the "value" of the slot.

I have hacs to slot-value-using-class (:around methods) that get the structure
and pull out the "real" value.  I have added a method called slot-explanation-using-class
that gets the structure and pulls out the rule pointer.  

I was very upset that Symbolics chose to hardcode the optimization of SLOT-VALUE, 
thus I have no recourse as I did in PCL to un-optimize calls for certain classes.
Thus my code doesn't work unless I call slot-value-using-class directly.  So I have
my own version of slot-value in a different package that never gets optimized.
						
2.  Definition of DOMAIN-SLOT-MIXIN, mixed with STANDARD-EFFECTIVE-SLOT-DEFINITION
and STANDARD-DIRECT-SLOT-DEFINITION.

Slot-definitions get extra slots.  This should be easy, but:

 a) Obviously, it would have been nice if ENSURE-CLASS could be extended to
    parse user-defined slot options.   

 b) Dumping a class has to "unparse" the slot definitions, such that reloading
    the dumped structure will completely restore the extra slots of the slot
    definitions.  This has been a very difficult problem, solved in an ugly way
    with an :around method to MAKE-LOAD-FORM, which appends the "unparsed"
    slot definitions to the end of the form.  This could be solved more elegantly if
    ENSURE-CLASS could parse my options, then the load form could somehow be the same as
    the macroexpansion of DEFCLASS.

 c) Slot inheritance still seems a littly sticky to me at times.  It ought to
    be easy to modify a direct-slot-definition and then have some high-level
    method to update all the effective-slot-definitions that care.

    I have done it by writing an :around method to COMPUTE-EFFECTIVE-SLOT-DEFINITION that
    filters out the nonstandard options	and does the right thing.  To update
    slot-inheritance, I call REINITIALIZE-INSTANCE on the class, which always seemed
    like overkill to me.

3.  Definition of SIMPLE-FUNCALLABLE-INSTANCE, an instance that is funcallable but has
no methods or dispatch code and doesn't install the definition in the function cell of
some symbol.

This seemed relatively easy in Symbolics CLOS, however I had no hook on the function
of the funcallable instance.  The Symbolics hook is the function:
      clos-internals::%funcallable-instance-function

This function takes an "extra arg" that took some time to figure out.  It turns out
that the extra arg is the environment of the closure, and I needed another hook to
go from the environment object to the fin itself, so that the body of my function
could access slots on the fin.
      clos-internals::%FUNCALLABLE-INSTANCE-EXTRA-ARGUMENT-FUNCALLABLE-INSTANCE

[KRA: Let me clarify this paragraph somewhat.  Jeff wanted to replace
the fin's function, so he had to figure out how to do that, and also
figure out what arguments the fin's function actually took.  We had
some sources, but most of what happens, is done in microcode.  Our
model is that fins are slightly different lexical-closures.  Lexical
closures consist of [environment, function], while a fin looks like
[extra-arg, fin-function] (total asside to Symbolics: what is
interesting is that on Ivory's a fin-function can be a lexical
closure, but on 3600's they must be a function!?)  The extra arg is a
defstorage object describing the fin.
Jeff also wanted some other slots, and wanted his fins to be anonymous
so he couldn't specialize STANDARD-GENERIC-FUNCTION :RAK]

Funcallable instances are an extremely powerful programming abstraction, beyond
their utility as the basis for generic functions, and therefore I believe they
should be standardized as a part of the language.

jeff morrill

------- End of Forwarded Message