Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA18408; Sun, 4 Mar 90 15:31:26 -0800 Received: from STONY-BROOK.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Sun 4 Mar 90 17:28:32-CST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 754574; 4 Mar 90 18:28:02 EST Date: Sun, 4 Mar 90 18:28 EST From: David A. Moon Subject: Proposed de facto standard subset of metaobjects To: Common-Lisp-Object-System@MCC.COM Message-Id: <19900304232802.8.MOON@EUPHRATES.SCRC.Symbolics.COM> 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.