CLIM mail archive
Question concerning methods
Now, I haven't found a legal way to get the lambda-list of a generic
function. In Allegro4.1, it is in the slot "CLOS::PRETTY-ARGLIST", in
Lucid, it is in the slot "CLOS::LAMBDA-LIST" of the generic function
I believe most vendors are adhering to David Moon's Proposal for the
MetaObject protocal for introspection. GENERIC-FUNCTION-LAMBDA-LIST
is the equivalent of CLOS::LAMBDA-LIST and is part of Lucid's
forthcoming 4.1 release.
John S. Kern
================ copy of proposal =======================
Date: Sun, 4 Mar 90 18:28 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Proposed de facto standard subset of metaobjects
. . .
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.
. . .
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
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
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:
STRUCTURE-SLOT-DEFINITION. These are not being proposed for standardization
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
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
COMPUTE-APPLICABLE-METHODS CLOS generic function
DESCRIBE-OBJECT CLOS generic function
DOCUMENTATION CLOS generic function, SETFable
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
MAKE-INSTANCE CLOS generic function
MAKE-INSTANCES-OBSOLETE CLOS generic function
MAKE-LOAD-FORM CLOS generic function
MAKE-METHOD ***No global definition found***
METHOD class name
METHOD-COMBINATION class name, DOCUMENTATION type
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-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-ADDED-METHODS ***No global definition found***
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.
Main Index |