[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


    Date: Wed, 29 Aug 90 11:01:33 EDT
    From: kab@charon.MIT.EDU (Kim A. Barrett)

    I recently found another class name in 88-002R which may not have been
    officially blessed.  The DOCUMENTATION generic function has a primary
    method specialized on the class STANDARD-SLOT-DESCRIPTION.  I have not
    been able to find any other mention of this class in 88-002R or the
    draft standard, and it was not included in either of the issues from
    the 6/90 meeting which made some of the random CLOS metaobject classes

I think what you are seeing is that much of the text in chapter 2 was written
with the assumption that chapter 3 would exist.  When chapter 3 was goal-reduced,
chapter 2 was not rewritten to reflect that fact.

    If we are going to be consistent about these, then we should also have
    a SLOT-DESCRIPTION class (with the exception of OBJECT, for every
    class named STANDARD-xxx we currently have a class named xxx).  Note
    also that the most recent draft of CLOS Chapter 3 I've seen (dated
    6/6/90) calls these classes STANDARD-SLOT-DEFINITION and
    SLOT-DEFINITION.  I personally have a mild preference for DESCRIPTION
    rather than DEFINITION.

I prefer the spelling DEFINITION over DESCRIPTION.  DESCRIPTION sounds
to me like a documentation string rather than an object.

    Do we want to say anything at all about these classes in the standard?
    Since I don't think they are very useful without a metaobject
    protocol, perhaps we should just forget them and remove the reference
    from the description of the DOCUMENTATION function.

I don't see any point in documenting methods specialized to metaobjects when
we don't have a metaobject protocol.  Documenting the methods is mainly for
the benefit of users defining their own methods, so they know where the
system methods are and whether they will be shadowing them or not.  But in 
the absence of a metaobject protocol users can't usefully define their own
methods.  However, maybe there is some reason I'm not seeing why these
methods should be documented in chapter 2 rather than chapter 3, and hence
be included in the ANSI Common Lisp spec.

    Date: Wed, 29 Aug 90 08:29:59 PDT
    From: Jon L White <jonl@lucid.com>

    Last winter, Moon and I came up with what seemed to be a de-facto
    standard for a meta-object protocol --  not the "last word", but a
    minimally useful subset that Symbolics, Lucid, and the latest PCL
    could generally agree upon (I think Franz too gave assent by silence).

I don't think it was by silence.  I vaguely remember Franz explicitly agreeing
that it was a good step.

    class names, along with several score of "introspective" functions.
    Dave sent out the entire proposal to common-lisp-object-system@mcc.com
    on March 4, 1990.

Agreed.  By the way, this was explicitly not proposed to be included in ANSI
Common Lisp, only to be a first step towards an agreed upon metaobject protocol
beyond ANSI Common Lisp.