Re: user interface macros

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

[Comments on excerpts from your message (actually written Friday, but
mailed Monday).  I'll comment on the environment issue separately.]

    Date: Wed, 2 May 90 16:13 PDT
    From: Gregor J. Kiczales <Gregor.PA@Xerox.COM>

    For example, Scott proposes a full-featured mechanism for metaclass
    control over the parsing of DEFCLASS forms into calls to ENSURE-CLASS.
    I have experimented with things like this in the past, and the one Scott
    proposes is a nice one.  But, I don't think we want to specify this sort
    of thing right now.  I feel like it is more than we want to get into,
    especially given JonL's valid points that the uimacros are the least
    important part of this whole thing.

I think that is a reasonable attitude.  I think we mentioned that more as
an example of what might be done than as a proposal for what should be done.
The problem is that you opened the door to user-defined new class options
and slot options by attempting to define how DEFCLASS would pass them through,
and since what you defined didn't really work, we wanted to explore what it
would take to make something that would work for all cases.  Unless I'm
missing something, I think it's been demonstrated that nothing really
simple will do the job of allowing users to pass their own options through
DEFCLASS in a satisfactory way.

    So, on the subject of extending the syntax of DEFCLASS, I propose:

      - remove the part about what happens when an option (any option) is
	specified more than once.  Just say it is not specified, that
	implementations are free to document their own behavior.

Okay.

      - either
     
	  - fix the :metaclass and :documentation class options and leave
	    the stuff about the tail of the list (this is what I had in
	    mind originally and failed to write)

	  or

	  - make the class options (other than :default-initargs) pass
	    the CADR

I'm not sure I understand this, but if it means define what each of the
standard class options turns into, and define that :metaclass and
:documentation pass a symbol and a string (rather than a list), I agree.

      - explicitly mention that implementations are free to have specific
	mechanisms for extending the behavior of the ui macros.

Okay.

      - fix the stuff about order to say only:

	   - the order of :default-initargs is preserved

	   - and possibly that for unspecified slot and class options,
	     they the specified ones and their order is preserved

I was unable to understand this, probably due to typos.

To be specific, I think what you want to do about DEFCLASS is to define
precisely how each of the standard options is passed through, and not to
define at all whether and how nonstandard options are passed through,
other than to mention that nonstandard options might be present and to
discuss the naming restrictions (packages).

	In the arguments to ENSURE-CLASS, this document has :DIRECT-SUPERCLASSES and
	:DIRECT-SLOTS where 89-003 has :SUPERCLASSES and :SLOTS.  Symbolics CLOS uses
	:DIRECT-SUPERCLASSES (based on mail with Gregor a few months ago) but :SLOTS.
	For consistency, :DIRECT-SLOTS would be better, but we've passed the point of
	being able to remove :SLOTS, although we could make :SLOTS mean :DIRECT-SLOTS.

	Similarly, :DIRECT-DEFAULT-INITARGS should replace :DEFAULT-INITARGS.
	Although no document and no implementation uses :DIRECT-DEFAULT-INITARGS
	currently, it would be more consistent.

    It's difficult for me to tell what you are asking for here.  The change
    to :DIRECT-XXX was based on the mail you mention.   I really think these
    are better names.  Unless someone complains I would like to leave these
    as:

       :DIRECT-SLOTS
       :DIRECT-SUPERCLASSES
       :DIRECT-DEFAULT-INITARGS

Your document says :DEFAULT-INITARGS, not :DIRECT-DEFAULT-INITARGS.  We were
suggesting :DIRECT- for all three of these things that get inherited.

     
	     A canonicalized default initarg is a list of three elements.
      ....
      * I don't think making the lists longer is the most modular way
	to do the extension you mention.  Instead, another keyword
	argument/initarg which parallels this one should be used.

I don't think so, because then the thing that combines the direct default
initargs to produce the complete list of default initargs would have to know
about this other list and make sure to keep the two of them synchronized.
Of course, the real error here is that the default initargs are materialized
as lists rather than using a more abstract data type, and do not go through
a stage of alternating keywords and values.  If the default initargs were
handled like the slots, none of these problems would arise.  However, I am
not advocating such a sweeping change.
     
	     \item{\bull} The value of the {\bf :specializers} initarg is a list of the
	     specializer names for the method.  For {\bf eql} specializers, this is a
	     list in which the first element is the symbol {\bf setf} and the second
	     element is the result of evaluating the eql specializer form in the lexical
	     environment of the {\bf defmethod} form.  For any other kind of
	     specializer, this is the value from the {\bf defmethod} form with no
	     special processing done.
     
	It's too weird to make this a list of elements that are parameter specializers
	in one case and parameter specializer names in the other case.  89-003 p.3-69
	requires parameter specializers here, i.e. classes rather than class names.
	See also 89-003 p.3-16.  So not only is this weird, it's also a gratuitous
	incompatibility.

    Actually, I don't think its weird, but I am willing to change it back.
    I believe, as I alluded to before, that there are three layers.

      1) the macroexpansion layer
      2) the name to metaobject mapping layer
      3) the anonymous metaobjects (where the real CLOS behavior is)

    The way this worked in 89-003 and the way you have it puts stuff from
    layer 2 in layer 1, and that isn't modular.

This is hardly the only place where the macroexpansion layer uses metaobjects.
I think a complete separation of the layers is simply not possible.

	Date: Fri, 27 Apr 90 17:58 EDT
	From: Cyphers@STONY-BROOK.SCRC.Symbolics.COM,
	      Moon@STONY-BROOK.SCRC.Symbolics.COM

	When defmethod calls ensure-generic-function, it must not supply the
	:lambda-list argument.  ensure-generic-function has to know the difference
	between a call from defgeneric (which always replaces the lambda-list),
	and a call from defmethod (which never replaces the lambda-list).
	Symbolics CLOS works as outlined in this message:


	Date: Fri, 27 Apr 90 17:08:50 PDT
	From: Jon L White <jonl@lucid.com>

	A gap in the current definition of ENSURE-GENERIC-FUNCTION?

    Based on the comments you have sent, here is a strawman.  What if we
    have ENSURE-GENERIC-FUNCTION accept two keyword arguments: :LAMBDA-LIST
    and :METHOD-LAMBDA-LIST.

    The :LAMBDA-LIST argument will be passed in by DEFGENERIC.  Its value
    will the the value specified in the macro form.  Its presence (or
    non-nullness) will indicate the call was from DEFGENERIC.

    The :METHOD-LAMBDA-LIST argument will be passed in by DEFMETHOD.  Its
    value will be the unspecialized lambda list from the macro form
    (what you get by calling extract-lambda-list).  Its presence (or
    non-nullness) will indicate the call was from DEFMETHOD.

    This means that special processing will happen inside of ENSURE-GF and
    initialization when DEFMETHOD creates a generic function, but this
    scheme should make all the information each of you wants available.

I think it would be much cleaner to handle the meeting of the method
lambda list and the generic function lambda list in ADD-METHOD, the
same place where all other method-meets-generic-function processing
is performed.  Do you disagree with this, or did you just not consider
it yet?