Page 208 Table of Contents Index Page 210
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30
A, B, C, D, E


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-
and presentation-subtypep that handle the parameters, or inherit appropriate pre-
sentation methods. In many cases it should also define presentation methods for describe-
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, is evaluated.

23.3.2 Presentation Type Abbreviations

=> define-presentation-type-abbreviation name parameters equivalent-type &key options [Macro]
name, parameters, and options are as in define-presentation-type. This defines a presenta-
tion type that is an abbreviation for the presentation type equivalent-type. Presentation type
abbreviations can only be used in places where this specification explicitly permits them. In such
places, equivalent-type and abbreviation are exactly equivalent and can be used interchangeably.

name must be a symbol and must not be the name of a CLOS class.

The equivalent-type form might be evaluated at compile time if presentation type abbreviations
are expanded by compiler optimizers. Unlike inherit-from, equivalent-type can perform arbitrary
computations and is not called with dummy parameter and option values. The type specifier
produced by evaluating equivalent-type can be a real presentation type or another abbreviation. If
the type specifier doesn't include the standard option :description, the option is automatically
copied from the abbreviation to its expansion.

Note that you cannot define any presentation methods on a presentation type abbreviation. If
you need methods, use define-presentation-type instead.

define-presentation-type-abbreviation is used to name a commonly used cliche. For ex-
ample, a presentation type to read an octal integer might be defined as

Page 208 Table of Contents Index Page 210
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30
A, B, C, D, E