user interface macros

[Jon L White <jonl@lucid.com>]

re: 
    > 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).

    That would be sufficient for implementation-defined options, but
    non-standard options should also include user-defined options.  In order
    for the metaclass writer to be able to define new options, there needs to
    be a standard correspondence between the DEFCLASS form and the arguments to
    ENSURE-CLASS-USING-CLASS.

I hope nothing prevents the "metaclass writer" from calling ENSURE-CLASS
and ENSURE-CLASS-USING-CLASS directly; nothing should require all class 
creations to go through DEFCLASS.

At some level, we have to be interested in how DEFCLASS, etc expand;
but not necessarily in a specification level.  Rather, as one of Scott's
notes shows, we need to be able to assure ourselves that the underlying
functional layer is good enough to do what any portable definition of
DEFCLASS would want it to do.  [As we found with ENSURE-GENERIC-FUNCTION,
there was a gap.]  So a fundamental question would first be: "How
does ENSURE-CLASS treat non-standard options in its arguments that
specify slot or class options?"   A typical answer could be something 
like "implementations are free to extend ...".  Or, these options might
even be specified to be passed along to the required initialization
methods that ENSURE-CLASS would call [see my previous note about the
good steps taken in this direction by the the "Rainy Day" PCL.]


In order to re-use the name DEFCLASS for non-standard class definitions, 
the macroexpansion handling of non-standard options -- both as class 
options and slot options -- would have to be assured.  But this ought to 
be an easy task, and one not particularly important to the overriding task
at hand, namely a user-visible metaobject protocol.  I fear the discussion 
has tended to veer away from the original goal of a meta-object protocol, 
and wandered too much into the realm of previously unsolved, related 
compilation problems which are essentially irrelevant to this overriding
goal;  an overemphasis on the particulars of the ui expansions could
have the same bad effect.

Other than using our current expectations about what the various ui macros 
mean (when evaluated), I don't see much gained towards the metaobject 
protocol by discussing them now.  There is a reason why only these macros 
-- as opposed to the underlying functional layger -- appear in the spec, 
but it is *not* due to their preeminent importance; note the explanation 
from my not of a week or so ago.

    Date: Fri, 27 Apr 90 17:08:50 PDT
    From: Jon L White <jonl>
    To: gregor.PA@Xerox.COM

    . . . 

    Rather, I think the only point of mentioning the expansion of the
    definer "user interface" macros is that our experience with metaobject
    creations over the past two years, via portable constructs, *had* to
    be limited to these macros.  So it's natural that we would tend to think 
    of the issues involved in terms of the exterior interface syntax.  Some 
    of you who have been on the Common-Lisp-Object-System mailing list for a 
    long time may remember that precisely this question arose several years 
    ago.  And someone (who? maybe Dave Moon) suggested that while we indeed 
    needed the functional interface for class, method, and generic function 
    creations, the predominate usage by end users would be in terms of the 
    succinct definer macros like DEFCLASS and DEFMETHOD.  Thus we *had* to 
    have syntax and semantics for these macros defined in the basic document; 
    but the definitions for the functional interface, while logically more 
    primitive, could be  postponed until the metaboject layer became more 
    fully defined.  Indeed the need by an end-user for the functional layer 
    would only really come into play when his application became involved in 
    "meta" manipulations.


From a later reply, it looks like Gregor missed the point of that
paragraph by stumbling over the first sentence.  Maybe reading the
last two sentences first will make it clearer.


-- JonL --