Comments on metaobject draft 10

[David Moon <moon@scrc-pegasus>]

Comments from Moon on 89-003 MOP draft number 10

I didn't make it all the way through the document, but here are
the comments I was able to come up with.  This is a big advance
over the previous draft I read, some time in early fall.

3-6..8: A few attributes of metaobjects seem to be missing here.
Names for classes and generic functions, documentation strings
for classes, generic functions, and methods.  Is this just an
oversight or does it represent some kind of modularity decision
where there is a level that does not have these attributes?

3-7: How come direct slot definitions have names of generic
functions in them, rather than generic function objects?

3-9: Some problems with the inheritance structure table:
It claims metaobject is a subclass of function, which is
surely untrue.  What is the metaclass of structure-object?
The caption implies standard-class, but I would expect that
it is really structure-class.  Also I would really expect
the metaclass of t to be a special metaclass just for t,
rather than built-in-class; is it allowed to be a subclass of
built-in-class?  I don't like the name "dependee-mixin", I
think "redefinable" might be a better word than "dependee."

3-10: "The default class of method combination objects is
not specified."  This seems inconsistent, I wonder if we
want to change it.  The short form and the long form of
define-method-combination would likely use different classes.

3-11: I think rule 3 doesn't work, for the same reason I
complained about last time.  I haven't rechecked this.

3-11: Rule 5 says implementations can define unspecified
:before and :after methods, what about :around?

3-11: Rule 8 is slightly wrong, see the cleanup issue PACKAGE-CLUTTER.
The way you say that slot names can't be in packages the user knows
about is more complex.  It would be better if ANSI Common Lisp just had
a word for it so we didn't have to keep saying it over and over.  This
issue also arises in the section on expansion of the user interface
macros.

3-13ff: The whole section on expansion of the user interface macros
is totally screwed up, as I think you know.  Straightening out the
Common Lisp issues with EVAL-WHEN and lexical environments is a
prerecquisite for fixing this.  The biggest problem is deciding what
happens at macro expansion time versus what happens when the macro
expansion is evaluated.  These days I believe that nothing "essential"
should happen at macro expansion time.  I think compile-time method
and slot-description metaobjects should have their function slots
unbound -- except since the MOP doesn't define them to be slots, this
has to be said differently.  But it is an error to access the function.

A more difficult problem (I think this has been discussed inconclusively
in the mail) is the relation of the local and remote metaobjects in
compile-file; ideally creating a remote class should create remote
objects for all its superclasses and subclasses, so there are no
cross-environment links, but that would copy the entire meta-object
world, which would be too slow.  Hence you either have to indirect
through names, as Flavors does, or use a virtual-copy mechanism of
some sort.  I don't know whether a virtual copy mechanism will require
some kind of change of protocol, with some more user interface
functions taking an environment argument; indirecting through names
avoids that issue since the indirection is a name-to-object translation
that -always- requires an environment argument.  Comments?

3-17: Still on the user interface macros: there is something fundamentally
wrong with specifying load time and eval time separately.  What they do
should be equivalent at the level of abstraction used in the spec.

3-22: I believe the expansion of define-method-combination was
pretty well outlined in 88-002, unless that was only in our mail
discussions and did not get into the final document.

3-25: The whole slot-definition-elide-access-method-p (and relatives)
mechanism seems inconsistent with the rest of CLOS.  I would have
expected this to be handled by making the slot-descriptor and argument
to functions at the level of slot-value-using-class, then the class
of the slot descriptor contributes to selecting the applicable methods
and the optimization can be performed if and only if the built-in
method is the only applicable method.

3-26: The restriction mentioned against using an obsolete instance
that has not yet been updated may be unimplementable, or even
meaningless, in multiprocess systems (where a class can be redefined
at any instant that user code can be running).

3-29: The first object to add-dependent shouldn't be specified to
be a metaobject, since not all metaobjects work and some non-metaobjects
work.  It should be an object that you call "dependee" or I call
"redefinable".

3-32: This says add-direct-subclass is called when a class is redefined.
Is it also called when a class is initially defined?

3-33: For functions like add-method that appear in both chapter 2 and
chapter 3, should Common Lisp be amended to delete the chapter 2 version?
Or is it really intended to have two probably non-identical definitions
of these functions?

3-50: The ensure-class-using-class generic function should not have
&allow-other-keys in its arglist.  Recall that this means that there
should never be any argument checking on calls to this generic function,
which seems unlikely to be what you want.

I guess that's as far as I have gotten so far.  I suppose it would be
more useful for me to think about the expansion of the user interface
macros than to try to plow through the rest of the document (yet more
function descriptions).