Re: mop questions

[Gregor Kiczales <gregor@parc.xerox.com>]

   Date: 	Wed, 31 Oct 1990 03:12:55 PST
   From: davis@ilog.ilog.fr
	   
	   So what I'd like to know primarily is if you think this is a
   reasonable approach.  In particular, I'm not interested in challenging
   CLOS's decisions, just in figuring out the best way for EuLisp.

It seems perfectly reasonable to me to have DEFREADER and DEFWRITER
macros, and to remove the functionality from DEFCLASS of defining these.
CLOS made one choice about the style of its UI macros, this would just
reflect another.

But, two comments.  First, the reason to do so certainly isn't to help
the compiler.  Unless I am missing something, the compiler should be
able to do just as well well with the CLOS form as with explicit
DEFREADER/DEFWRITER forms.  

Second, I believe that if you were really going to do this right, the
only thing you would define is the underlying functionality---the
explicit metaobject manipulation layer.  None of these macros, or the UI
syntax in terms of Lispo forms would be defined.  Doing this would of
course require you to do a MOP for the underlying Lisp which is why
no-one has done it yet.  But then, instead of writing the specification
in terms of forms the compiler understands, you would write it in terms
of metaobjects the compiler can compile and the interpreter can run.
There would be application metaobjects, lambda metaobjects, etc. etc.

This would then put you in a much better situation to write the
programming environment.  You could use any interface you wanted.  Text
and text editors ala maclisp, structure and structure editors ala
interlisp, or fancy graphical structures and editors ala Units.  There
would be no confusion about the language primitives being `forms' so
things would be much easier.

   I apologize for this question.  I made some bad assumptions based on
   some slightly obscure language in 88-002R page 2-28 and a stronger
   TELOS restriction on generic functions.  

Right, this is a bug in CLOS.  We should have an option on DEFMETHOD
that allows you to control the class of the method created, that would
make it more clear than generic functions can have methods of different
classes and that the role of the :method-class option to DEFGENERIC is
just to set the default method class for the generic function.

   What issues are you thinking about here?  These questions about slot
   definition metaobjects are particularly interesting to me, since it is
   one of the areas in which TELOS differs the most from CLOS.

The kind of thing that comes up when you are about to create a
(meta)object and different participants in that process are trying to
alter the default class in different ways.  In the class of slot
definition metaobjects, imagine that the class is trying to say, use a
class which is the default class plus this other mixin(A).  At the same
time one of the slot definitions is trying to say use the default class
plus this other mixin(B).  What you often end up wanting to do is cons
up a new class, with a cpl of (#:new-class A B default ...).  That works
pretty well, but we don't have enough experience with programming with
dynamically created classes that I wanted to put any language like that
in the spec.

   The version of the AMOP that I have does not discuss slot definition
   metaobjects.

Right, but when you see it defining new `accessors' for a slot
definition "metaobject", read that as defining a new subclass of the std
kind of slot definition metaobject.

   So do you see a class as having only one kind of slot definition for
   all of its slots?

No, I don't.  This move by Eulisp seems like a move in the right
direction.  As I said above, I think you should also be able to control
the class of the method metaobject from the method defining form.

   PS I received two copies of each of your messages, as well as a
   message from the PARC postmaster with the following error:

We are working on this.