[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proposed de facto standard subset of metaobjects
I've noticed that the CLOS standard consists of three parts, only one of
which is becoming an actual standard, and I want to do something about it.
The three parts are: the stuff that's being standardized in ANSI CL
(basically the 88-002R report as amended by later X3J13 actions), the basic
metaobject stuff that everyone has to have for internal reasons anyway, and
the blue-sky metaobject stuff that isn't really figured out yet, which allows
you to do hairy things like use CLOS to build entirely new object systems.
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 believe the
second part is pretty important for a number of programs, including CLIM and
applications based on CLIM. 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. This would not be so much a standard as simply
people agreeing not to become inconsistent for no reason. Programs written
using these features would not be fully ANSI Common Lisp compliant, but in
practice would be moderately portable if most CLOS implementations agree on a
de facto standard.
The full CLOS metaobject facility provides a model of the system that can be
used both for introspection (a program examining its own structure) and for
extension (changing the behavior of metaobjects and implementation of new
object-oriented languages within the CLOS framework). What is being proposed
here is only introspection. 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.
What Symbolics and Lucid have both done is to go through the 89-003 report
(Gregor's draft proposal for metaobjects) and use the names proposed there for
anything that seems to make sense to standardize on at this time, while skipping
over anything that looks like it is not really figured out yet, and leaving out
everything that is not needed to do just introspection. We'd like to propose
this set of names with these spellings as at least a starting point for a de
facto standard. Symbolics uses these names both in Genera 8.0 CLOS and in Cloe
3.0 CLOS (neither of which is released yet, but will be soon). Genera runs on
Symbolics 3600 and Ivory hardware, Cloe runs on Intel 386 hardware. Lucid uses
these names in the upcoming Lucid 4.0 release (now in Beta test on SUN
hardware). Both Symbolics and Lucid have a few slight differences from this
proposal in their upcoming releases, because the releases had to be frozen
before the proposal was finished; those differences are noted below. I'd like
to get other CLOS implementors, in addition to Lucid and Symbolics, involved in
this informal standard.
For now we are only proposing names, not precise definitions of what they do.
The definitions will be necessary, but they are a lot of work so we'll do
that later, after we see whether it is possible to agree on the names.
At Symbolics we came up with three packages (COMMON-LISP, CLOS, and
CLOS-INTERNALS). COMMON-LISP is the package whose contents is defined by
ANSI Common Lisp. CLOS is the package that exports all the "standardized"
symbols of CLOS, not only the ones defined by ANSI Common Lisp but also some
others that make sense to standardize on in a de facto way. The idea is that
a program can :USE CLOS in its DEFPACKAGE, or use CLOS: package prefixes
throughout the program, to get the CLOS facilities that one would expect to
be portable to other implementations. The name and existence of the CLOS
package is part of the proposed de facto standard. CLOS-INTERNALS exports
the things that we might want wizardly users and our own tools to use, but
that are not being proposed for standardization. Things in CLOS-INTERNALS
are not necessarily compatible even among Symbolics' own various
implementations and are not being proposed as a standard. There's no need
even to agree on the name of that package; indeed, Lucid does not use that
particular package name.
Exporting the ANSI Common Lisp standardized symbols of CLOS from the package
named CLOS facilitates using CLOS in programs that are otherwise written
using the CLtL dialect rather than the ANSI dialect.
I believe the policy we're working from can be succinctly stated as "exports
from the CLOS package are all and only those symbols which are the current
(draft proposed) ANSI standard CLOS or seem likely to be recommended for
future ANSI standardization."
The remainder of this message lists the proposed external symbols of the CLOS
package, in three parts. The first part is a list of the extensions to
standardized CLOS being proposed at this time. The second part is a list of
additional extensions that only apply to Common Lisps that support locatives.
That list is being proposed at this time, but does not apply to most Common
Lisp implementations; these symbols would only exist in implementations that
actually have locatives. The third part is a list of the symbols in
standardized CLOS, for completeness.
NON-ANSI-STANDARD SYMBOLS EXPORTED BY THE CLOS PACKAGE:
CLASS-DEFAULT-INITARGS CLOS generic function
CLASS-DIRECT-DEFAULT-INITARGS CLOS generic function
CLASS-DIRECT-SLOTS CLOS generic function
CLASS-DIRECT-SUBCLASSES CLOS generic function
CLASS-DIRECT-SUPERCLASSES CLOS generic function
CLASS-PRECEDENCE-LIST CLOS generic function
CLASS-PROTOTYPE CLOS generic function
CLASS-SLOTS CLOS generic function
COMPUTE-EFFECTIVE-METHOD CLOS generic function
FORWARD-REFERENCED-CLASS class name
FUNCALLABLE-STANDARD-CLASS class name
GENERIC-FUNCTION-ARGUMENT-PRECEDENCE-ORDER CLOS generic function
GENERIC-FUNCTION-DECLARATIONS CLOS generic function
GENERIC-FUNCTION-INITIAL-METHODS CLOS generic function
GENERIC-FUNCTION-LAMBDA-LIST CLOS generic function
GENERIC-FUNCTION-METHOD-CLASS CLOS generic function
GENERIC-FUNCTION-METHOD-COMBINATION CLOS generic function
GENERIC-FUNCTION-METHODS CLOS generic function
GENERIC-FUNCTION-NAME CLOS generic function
METHOD-FUNCTION CLOS generic function
METHOD-GENERIC-FUNCTION CLOS generic function
METHOD-LAMBDA-LIST CLOS generic function
METHOD-SLOT-NAME CLOS generic function
METHOD-SPECIALIZERS CLOS generic function
SLOT-BOUNDP-USING-CLASS CLOS generic function
SLOT-DEFINITION class name
SLOT-DEFINITION-ALLOCATION CLOS generic function
SLOT-DEFINITION-INITARGS CLOS generic function
SLOT-DEFINITION-INITFORM CLOS generic function
SLOT-DEFINITION-INITFUNCTION CLOS generic function
SLOT-DEFINITION-NAME CLOS generic function
SLOT-DEFINITION-READERS CLOS generic function
SLOT-DEFINITION-TYPE CLOS generic function
SLOT-DEFINITION-WRITERS CLOS generic function
SLOT-EXISTS-P-USING-CLASS CLOS generic function
SLOT-MAKUNBOUND-USING-CLASS CLOS generic function
SLOT-VALUE-USING-CLASS CLOS generic function, SETFable, LOCFable
SPECIALIZER-DIRECT-GENERIC-FUNCTIONS CLOS generic function
SPECIALIZER-DIRECT-METHODS CLOS generic function
STANDARD-ACCESSOR-METHOD class name
STANDARD-READER-METHOD class name
STANDARD-SLOT-DEFINITION class name
STANDARD-WRITER-METHOD class name
Notes:
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.
Using SETF with any of these names not indicated to be SETFable should
signal an error.
The following symbols are exported from the CLOS package by both Symbolics and
Lucid, but are not being proposed for a standard at this time, for the reasons
given:
CLASS-DIRECT-METHODS use SPECIALIZER-DIRECT-METHODS
CLASS-FINALIZED-P not needed for introspection
COMPUTE-CLASS-PRECEDENCE-LIST use CLASS-PRECEDENCE-LIST
SPECIALIZER-DIRECT-METHODS is more general than CLASS-DIRECT-METHODS.
COMPUTE-CLASS-PRECEDENCE-LIST is needed for extension, where users
define new methods for it to implement different CPL rules, but for
introspection it is just a slower version of CLASS-PRECEDENCE-LIST.
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.
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.
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
Notes:
These names are only meaningful in implementations that have the "locatives"
extension, and would not exist in other implementations. They do not exist in
Symbolics Cloe, nor in Lucid.
Where a function is listed as "LOCFable", that attribute only applies in
implementations that have the "locatives" extension.
ANSI-STANDARD SYMBOLS EXPORTED BY THE CLOS PACKAGE:
While we're at it, I might as well include this list of the symbols that
Symbolics thinks are defined by the CLOS standard. These are all the symbols
with pages in chapter 2 of 88-002R, plus other symbols that are mentioned in
88-002R with the apparent intention of being part of the standard, plus
several symbols added by later X3J13 actions.
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. Lucid also has not yet implemented
DEFINE-METHOD-COMBINATION. The other missing global definitions are because
the standard specifies only a local definition for those symbols. I think a
careful reading will also show that the implementation from which this table
was generated has not yet implemented a couple of specified condition types.
Lucid exports all of the symbols listed here except for MAKE-LOAD-FORM and
MAKE-LOAD-FORM-SAVING-SLOTS, which are not implemented yet. (A few others
are only exported by a last-minute patch to the Lucid 4.0.0 Beta-1 version.)
ADD-METHOD CLOS generic function
ALLOCATE-INSTANCE CLOS generic function
BUILT-IN-CLASS class name
CALL-METHOD ***No global definition found***
CALL-NEXT-METHOD ***No global definition found***
CHANGE-CLASS CLOS generic function
CLASS class name
CLASS-NAME CLOS generic function, SETFable
CLASS-OF function
COMPUTE-APPLICABLE-METHODS CLOS generic function
DEFCLASS macro
DEFGENERIC macro
DEFINE-METHOD-COMBINATION macro
DEFMETHOD macro
DESCRIBE-OBJECT CLOS generic function
DOCUMENTATION CLOS generic function, SETFable
ENSURE-GENERIC-FUNCTION function
FIND-CLASS function, SETFable
FIND-METHOD CLOS generic function
FUNCTION-KEYWORDS CLOS generic function
GENERIC-FLET ***No global definition found***
GENERIC-FUNCTION class name
GENERIC-LABELS ***No global definition found***
INITIALIZE-INSTANCE CLOS generic function
INVALID-METHOD-ERROR function
MAKE-INSTANCE CLOS generic function
MAKE-INSTANCES-OBSOLETE CLOS generic function
MAKE-LOAD-FORM CLOS generic function
MAKE-LOAD-FORM-SAVING-SLOTS function
MAKE-METHOD ***No global definition found***
METHOD class name
METHOD-COMBINATION class name, DOCUMENTATION type
METHOD-COMBINATION-ERROR function
METHOD-QUALIFIERS CLOS generic function
NEXT-METHOD-P ***No global definition found***
NO-APPLICABLE-METHOD CLOS generic function
NO-NEXT-METHOD CLOS generic function
PRINT-OBJECT CLOS generic function
REINITIALIZE-INSTANCE CLOS generic function
REMOVE-METHOD CLOS generic function
SETF macro, DOCUMENTATION type
SHARED-INITIALIZE CLOS generic function
SLOT-BOUNDP function
SLOT-EXISTS-P function
SLOT-MAKUNBOUND function
SLOT-MISSING CLOS generic function
SLOT-UNBOUND CLOS generic function
SLOT-VALUE function, SETFable, LOCFable
STANDARD CLOS method-combination
STANDARD-CLASS class name
STANDARD-GENERIC-FUNCTION class name
STANDARD-METHOD class name
STANDARD-OBJECT class name
STRUCTURE-CLASS class name
STRUCTURE-OBJECT class name
SYMBOL-MACROLET special form
UPDATE-INSTANCE-FOR-DIFFERENT-CLASS CLOS generic function
UPDATE-INSTANCE-FOR-REDEFINED-CLASS CLOS generic function
WITH-ACCESSORS macro
WITH-ADDED-METHODS ***No global definition found***
WITH-SLOTS macro
Notes:
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. Note that LOAD-OBJECTS:MAKE-LOAD-FORM assumes the existence
of ALLOCATE-INSTANCE and that user-written MAKE-LOAD-FORM methods that return
two values will typically use ALLOCATE-INSTANCE in the first value. 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.