There is no record of what the second return value was meant to
indicate, and apparently no clients for it.
+
+@item
+@tindex generic-function
+@tindex standard-generic-function
+@tindex funcallable-standard-object
+@tindex sb-mop:funcallable-standard-object
+@tindex standard-object
+@tindex function
+The direct superclasses of @code{sb-mop:funcallable-standard-object} are
+@code{(function standard-object)}, not @code{(standard-object function)}.
+
+This is to ensure that the @code{standard-object} class is the last of
+the standardized classes before @code{t} appearing in the class
+precedence list of @code{generic-function} and
+@code{standard-generic-function}, as required by section 1.4.4.5 of the
+ANSI specification.
@item
@findex ensure-generic-function
@tindex function
@findex sb-mop:class-prototype
@findex class-prototype
-although SBCL obeys the requirement in AMOP for
-@code{validate-superclass} for @code{standard-class} and
-@code{funcallable-standard-class} to be compatible metaclasses, we
+although SBCL obeys the requirement in AMOP that
+@code{validate-superclass} should treat @code{standard-class} and
+@code{funcallable-standard-class} as compatible metaclasses, we
impose an additional requirement at class finalization time: a class
of metaclass @code{funcallable-standard-class} must have
@code{function} in its superclasses, and a class of metaclass
@findex typep
@findex class-of
@findex subtypep
-At class finalization, a class prototype which is accessible by a
-standard mop function @code{sb-mop:class-prototype}. The user can
-then ask whether this object is a @code{function} or not in several
-different ways: whether it is a function according to @code{typep};
-whether its @code{class-of} is @code{subtypep} @code{function}, or
-whether @code{function} appears in the superclasses of the class. The
-additional consistency requirement comes from the desire to make all
-of these answers the same.
+After a class has been finalized, it is associated with a class
+prototype which is accessible by a standard mop function
+@code{sb-mop:class-prototype}. The user can then ask whether this
+object is a @code{function} or not in several different ways: whether it
+is a function according to @code{typep}; whether its @code{class-of} is
+@code{subtypep} @code{function}, or whether @code{function} appears in
+the superclasses of the class. The additional consistency requirement
+comes from the desire to make all of these answers the same.
The following class definitions are bad, and will lead to errors
either immediately or if an instance is created:
@end lisp
and leads to a class whose instances are funcallable and have one slot.
+@tindex funcallable-standard-object
+@tindex sb-mop:funcallable-standard-object
+Note that this requirement also applies to the class
+@code{sb-mop:funcallable-standard-object}, which has metaclass
+@code{sb-mop:funcallable-standard-class} rather than
+@code{standard-class} as AMOP specifies.
+
@item
the requirement that ``No portable class @math{C_p} may inherit, by
virtue of being a direct or indirect subclass of a specified class, any
by symbols in the Common Lisp package: preventing two independent pieces
of software from colliding with each other.
+@item
+@findex slot-value-using-class
+@findex sb-mop:slot-value-using-class
+@findex (setf slot-value-using-class)
+@findex (setf sb-mop:slot-value-using-class)
+@findex slot-boundp-using-class
+@findex sb-mop:slot-boundp-using-class
+specializations of the @code{new-value} argument to @code{(setf
+sb-mop:slot-value-using-class)} are not allowed: all user-defined
+methods must have a specializer of the class @code{t}.
+
+This prohibition is motivated by a separation of layers: the
+@code{slot-value-using-class} family of functions is intended for use in
+implementing different and new slot allocation strategies, rather than
+in performing application-level dispatching. Additionally, with this
+requirement, there is a one-to-one mapping between metaclass, class and
+slot-definition-class tuples and effective methods of @code{(setf
+slot-value-using-class)}, which permits optimization of @code{(setf
+slot-value-using-class)}'s discriminating function in the same manner as
+for @code{slot-value-using-class} and @code{slot-boundp-using-class}.
+
+Note that application code may specialize on the @code{new-value}
+argument of slot accessors.
+
+@item
+@findex defclass
+@findex ensure-class
+@findex ensure-class-using-class
+@findex sb-mop:ensure-class
+@findex sb-mop:ensure-class-using-class
+@findex find-class
+@findex class-name
+the class named by the @code{name} argument to @code{ensure-class}, if
+any, is only redefined if it is the proper name of that class;
+otherwise, a new class is created.
+
+This is consistent with the description of @code{ensure-class} in AMOP
+as the functional version of @code{defclass}, which has this behaviour;
+however, it is not consistent with the weaker requirement in AMOP, which
+states that any class found by @code{find-class}, no matter what its
+@code{class-name}, is redefined.
+
+@end itemize
+
+In addition, SBCL supports extensions to the Metaobject protocol from
+AMOP; at present, they are:
+
+@itemize
+
+@item
+@findex defmethod
+@findex find-class
+@findex intern-eql-specializer
+@findex sb-mop:intern-eql-specializer
+@findex make-method-specializers-form
+@findex sb-pcl:make-method-specializers-form
+@findex make-method-lambda
+@findex sb-mop:make-method-lambda
+compile-time support for generating specializer metaobjects from
+specializer names in @code{defmethod} forms is provided by the
+@code{make-method-specializers-form} function, which returns a form
+which, when evaluated in the lexical environment of the
+@code{defmethod}, returns a list of specializer metaobjects. This
+operator suffers from similar restrictions to those affecting
+@code{make-method-lambda}, namely that the generic function must be
+defined when the @code{defmethod} form is expanded, so that the
+correct method of @code{make-method-specializers-form} is invoked.
+The system-provided method on @code{make-method-specializers-form}
+generates a call to @code{find-class} for each symbol specializer
+name, and a call to @code{intern-eql-specializer} for each @code{(eql
+@var{x})} specializer name.
+
+@item
+@findex find-method
+@findex parse-specializer-using-class
+@findex unparse-specializer-using-class
+@findex sb-pcl:parse-specializer-using-class
+@findex sb-pcl:unparse-specializer-using-class
+run-time support for converting between specializer names and
+specializer metaobjects, mostly for the purposes of
+@code{find-method}, is provided by
+@code{parse-specializer-using-class} and
+@code{unparse-specializer-using-class}, which dispatch on their first
+argument, the generic function associated with a method with the given
+specializer. The system-provided methods on those methods convert
+between classes and proper names and between lists of the form
+@code{(eql @var{x})} and interned eql specializer objects.
+
@end itemize
@node Support For Unix
@comment node-name, next, previous, up
@section Support For Unix
+@menu
+* Command-line arguments::
+* Querying the process environment::
+* Running external programs::
+@end menu
+
+@node Command-line arguments
+@subsection Command-line arguments
+@vindex sb-ext:*posix-argv*
+@vindex *posix-argv*
+
The UNIX command line can be read from the variable
-@code{sb-ext:*posix-argv*}. The UNIX environment can be queried with
-the @code{sb-ext:posix-getenv} function.
+@code{sb-ext:*posix-argv*}.
+
+@node Querying the process environment
+@subsection Querying the process environment
+
+The UNIX environment can be queried with the
+@code{sb-ext:posix-getenv} function.
@include fun-sb-ext-posix-getenv.texinfo
+@node Running external programs
+@subsection Running external programs
+
External programs can be run with @code{sb-ext:run-program}.
+@footnote{In SBCL versions prior to 1.0.13, @code{sb-ext:run-program}
+searched for executables in a manner somewhat incompatible with other
+languages. As of this version, SBCL uses the system library routine
+@code{execvp(3)}, and no longer contains the function,
+@code{find-executable-in-search-path}, which implemented the old
+search. Users who need this function may find it
+in @file{run-program.lisp} versions 1.67 and earlier in SBCL's CVS
+repository here
+@url{http://sbcl.cvs.sourceforge.net/sbcl/sbcl/src/code/run-program.lisp?view=log}. However,
+we caution such users that this search routine finds executables that
+system library routines do not.}
@include fun-sb-ext-run-program.texinfo
+When @code{sb-ext:run-program} is called with @code{wait} equal to
+NIL, an instance of class @var{sb-ext:process} is returned. The
+following functions are available for use with processes:
+
@include fun-sb-ext-process-p.texinfo
@include fun-sb-ext-process-input.texinfo
@node Tools To Help Developers
@comment node-name, next, previous, up
@section Tools To Help Developers
+@findex trace
+@findex inspect
SBCL provides a profiler and other extensions to the ANSI @code{trace}
facility. For more information, see @ref{Macro common-lisp:trace}.
@node Resolution of Name Conflicts
@section Resolution of Name Conflicts
+@tindex sb-ext:name-conflict
+@tindex name-conflict
+@findex sb-ext:name-conflict-symbols
+@findex name-conflict-symbols
The ANSI standard (section 11.1.1.2.5) requires that name conflicts in
packages be resolvable in favour of any of the conflicting symbols. In
projects / sbcl.git / blobdiff