Page 206	Table of Contents	Index	Page 208
	Chapters
	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

---

CHAPTER 23. PRESENTATION TYPES


name
(name parameters...)
((name parameters...) options...)

Note that name can be either a symbol that names a presentation type or a CLOS class object
(but not a built-in-class object), in order to support anonymous CLOS classes.

The parameters "parameterize" the type, just as in a Common Lisp type specifier. The func-
tion presentation-typep uses the parameters to check object membership in a type. Adding
parameters to a presentation type specifier produces a subtype, which contains some, but not
necessarily all, of the objects that are members of the unparameterized type. Thus the parame-
ters can turn off the sensitivity of some presentations that would otherwise be sensitive.

The options are alternating keywords and values that affect the use or appearance of the pre-
sentation, but not its semantic meaning. The options have no effect on presentation sensitivity.
(A programmer could choose to make a tester in a translator examine options, but this is not
standard practice.) The standard option :description is accepted by all types; if it is a non-
nil value, then the value must be a string that describes the type and overrides the description
supplied by the type's definition.

Every presentation type is associated with a CLOS class. If name is a class object or the
name of a class, and that class is not a built-in-class, that class is the associated class.
Otherwise, define-presentation-type defines a class with metaclass presentation-type-
class and superclasses determined by the presentation type definition. This class is not named
name, since that could interfere with built-in Common Lisp types such as and, member, and
integer. class-name of this class returns a list (presentation-type name). presentation-
type-class is a subclass of standard-class.

Implementations are permitted to require programmers to evaluate the defclass form first in
the case when the same name is used in both a defclass and a define-presentation-type.

Every CLOS class (except for built-in classes) is a presentation type, as is its name. If it has not
been defined with define-presentation-type, it allows no parameters and no options.

Presentation type inheritance is used both to inherit methods ("what parser should be used for
this type?"), and to establish the semantics for the type ("what objects are sensitive in this
input context?"). Inheritance of methods is the same as in CLOS and thus depends only on the
type name, not on the parameters and options.

During presentation method combination, presentation type inheritance arranges to translate
the parameters of a subtype into a new set of parameters for its supertype, and translates the
options of the subtype into a new set of options for the supertype.

23.3.1 Defining Presentation Types

=> define-presentation-type name parameters &key options inherit-from description history
parameters-are-types [Macro]

---

Page 206	Table of Contents	Index	Page 208
	Chapters
	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