7.2 CLIM Operators for Defining New Presentation 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
.

description
is a string or
nil
. This should be the term for an instance for the type being defined. If it is
nil
or unsupplied, a description is automatically generated; it will be a "prettied up" version of the type name, for example,
small-integer
would become
"small integer"
. You can also write a
describe-presentation-type
presentation method.
description
is implemented by the default
describe-presentation-type
method, so
description
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.