Proposed de facto standard subset of metaobjects

[David Gray <gray@lucid.com>]

> What concerns me is that the lack of progress on the third part has caused an
> unnecessary failure of standardization of the second part. 

I think there has been lack of progress on both the second and third parts
(although in the case of the second part, it appears to have been due more
to loss of interest than to any technical problems), but I'm glad to see an
effort to get things moving again.

> ...  What I'd like to do about this is to create a de facto standard by
> having everyone agree on the names to use for this basically
> non-controversial stuff.  ...

Sounds like a good goal; at least, better than nothing.  I still feel bad
that what you call the third part is apparently being allowed to lapse into
oblivion without ever being completed and without even publishing the
partial results so that someone else could continue the work.

>   ...   While extension is useful and needed, it is clearly more difficult
> and not as ready for standardization as introspection, so it will have to
> wait until later.

Some parts are readier than others.

>   	...	   We'd like to propose
> this set of names with these spellings as at least a starting point for a de
> facto standard.	...	 I'd like
> to get other CLOS implementors, in addition to Lucid and Symbolics,
> involved in this informal standard.

What you propose here is very similar to what has been done in release 6 of
the TI Explorer.  I'll comment on a couple of points here, but since I no
longer work for TI and don't even have access to an Explorer now, I can't
check all the details; perhaps someone at TI will do that.

> At Symbolics we came up with three packages (COMMON-LISP, CLOS, and
> CLOS-INTERNALS).	...

The Explorer has corresponding packages COMMON-LISP, CLOS, and TICLOS.  The
CLOS package export list includes the symbols from chapter 3 (although many
are not defined), while extensions are exported only from TICLOS.

> NON-ANSI-STANDARD SYMBOLS EXPORTED BY THE CLOS PACKAGE:

It looks like most, if not all, of these are already implemented on the
Explorer, although some may have been done after release 6 (which is what is
currently shipped to customers).

> The CLASS-xxx accessors always work, no explicit "finalize" is required.
> We're not sure whether this is a change from 89-003 or not.

The Explorer requires explicit finalization for certain accessors, as
specified in 88-003, since 89-003 does not say, and no one was interested in
discussing the question at the time.

> Lucid's CLOS package exports several additional symbols as well:
> LIST-ALL-CLASSES, TRACE-METHOD, UNDEFMETHOD, UNTRACE-METHOD.  These
> are not being proposed for standardization right now.

The Explorer has an UNDEFMETHOD macro, but it is exported from TICLOS (and
TICL), not CLOS.

> Symbolics' CLOS package exports several additional symbols as well:
> CLASS-DEFAULT-DIRECT-SUPERCLASSES, DIRECT-SLOT-DEFINITION,
> EFFECTIVE-SLOT-DEFINITION, STANDARD-DIRECT-CLASS-SLOT-DEFINITION,
> STANDARD-DIRECT-SLOT-DEFINITION, STANDARD-EFFECTIVE-SLOT-DEFINITION,
> STRUCTURE-DIRECT-SLOT-DEFINITION, STRUCTURE-EFFECTIVE-SLOT-DEFINITION,
> STRUCTURE-SLOT-DEFINITION.  These are not being proposed for standardization
> right now.

I believe that these were all implemented on the Explorer in the work I did
after release 6.

> NON-ANSI-STANDARD SYMBOLS EXPORTED BY THE CLOS PACKAGE, ONLY IN
> COMMON LISP IMPLEMENTATIONS THAT HAVE LOCATIVES:

>   SLOT-DEFINITION-LOCATORS                   CLOS generic function
>   STANDARD-LOCATOR-METHOD                    class name

The Explorer supports locatives, but I don't recognize what these names
would mean.  The Explorer permits defining methods on generic functions
named (LOCF SLOT-VALUE), (LOCF SLOT-VALUE-USING-CLASS), etc, by analogy to
(SETF ...) generic functions.

> ANSI-STANDARD SYMBOLS EXPORTED BY THE CLOS PACKAGE:
...
> Note that neither Symbolics or Lucid has implemented GENERIC-FLET,
> GENERIC-FUNCTION as a special form, GENERIC-LABELS, and WITH-ADDED-METHODS in
> their current implementations. 

These are implemented on the Explorer, except that WITH-ADDED-METHODS is a
hack that does not fully conform to the specifications (I agree that it
should be removed from the standard).

> Lucid also has not yet implemented DEFINE-METHOD-COMBINATION.

The Explorer has this.

The only obvious discrepancy I notice in the list of symbols is that the
Explorer unfortunately still implements SYMBOL-MACROLET as a macro instead
of a special form.

> ALLOCATE-INSTANCE did not get its own page in 88-002R, but (some of) the
> authors of that document say that was simply a mistake.  At this point there
> should probably be an X3J13 cleanup to clarify that ALLOCATE-INSTANCE is part
> of the language.

I agree.

>   ...  The symbol ALLOCATE-INSTANCE is not exported from the CLOS package
> by Genera 8.0, 
> but it is exported by Lucid.  The lack of export in Genera is just a bug.

It is exported from the Explorer's CLOS package.