Arguments: name parameters
options inherit-from description history parameters-are-types
Summary: Defines a presentation type whose name is the symbol or class name and whose parameters are specified by the lambda-list parameters . These parameters are visible within inherit-from and within the methods created with define-presentation-method . For example, the parameters are used by presentation-typep and presentation-subtypep methods to refine their tests for type inclusion.
options is a list of option specifiers. It defaults to nil . An option specifier is either a symbol or a list of the form ( symbol &optional default supplied-p presentation-type accept-options ), where symbol , default , and supplied-p are as in a normal lambda-list. If presentation-type and accept-options are present, they specify how to accept a new value for this option from the user. symbol can also be specified in the ( keyword variable ) form allowed for Common Lisp lambda lists. symbol is a variable that is visible within inherit-from and within most of the methods created with define-presentation-method . The keyword corresponding to symbol can be used as an option in the third form of a presentation type specifier. An option specifier for the standard option :description is automatically added to options if an option with that keyword is not present; however, it does not produce a visible variable binding.
Unsupplied optional or keyword parameters default to * (as in deftype ) if no default is specified in parameters . Unsupplied options default to nil if no default is specified in options .
inherit-from is a form that evaluates to a presentation type specifier for another type from which the new type inherits. inherit-from can access the parameter variables bound by the parameters lambda list and the option variables specified by options . If name is or names a CLOS class (other than a built-in-class ), then inherit-from must specify the class's direct superclasses (using and to specify multiple inheritance). It is useful to do this when you want to parameterize previously defined CLOS classes.
If inherit-from is unsupplied, the default behavior is that if name is or names a CLOS class, then the type inherits from the presentation type corresponding to the direct superclasses of that CLOS class (using and to specify multiple inheritance). Otherwise, the type named by name inherits from standard-class .
is a string or
. This should be the term for an instance for the type being defined. If it is
or unsupplied, a description is automatically generated; it will be a "prettied up" version of the type name, for example,
. You can also write a
is implemented by the default
only works in presentation types where that default method is not shadowed.
history can be t (the default), meaning that this type has its own history of previous inputs; nil , meaning that this type keeps no history; or the name of another presentation type whose history is shared by this type. More complex histories can be specified by writing a presentation-type-history presentation method.
If the boolean parameters-are-types is t , this means that the parameters to the presentation type are themselves presentation types. If they are not presentation types, parameters-are-types should be supplied as nil . Types such as and , or , and sequence will specify this as t .
Every presentation type must define or inherit presentation methods for accept and present if the type is going to be used for input and output. For presentation types that are only going to be used for input via the pointer, the accept need not be defined.
If a presentation type has parameters , it must define presentation methods for presentation-typep and presentation-subtypep that handle the parameters, or inherit appropriate presentation methods. In many cases it should also define presentation methods for describe-presentation-type and presentation-type-specifier-p .
There are certain restrictions on the inherit-from form, to allow it to be analyzed at compile time. The form must be a simple substitution of parameters and options into positions in a fixed framework. It cannot involve conditionals or computations that depend on valid values for the parameters or options; for example, it cannot require parameter values to be numbers. It cannot depend on the dynamic or lexical environment. The form will be evaluated at compile time with uninterned symbols used as dummy values for the parameters and options. In the type specifier produced by evaluating the form, the type name must be a constant that names a type, the type parameters cannot derive from options of the type being defined, and the type options cannot derive from parameters of the type being defined. All presentation types mentioned must be already defined. and can be used for multiple inheritance, but or , not , and satisfies cannot be used.
None of the arguments, except inherit-from , are evaluated.