ISO/IEC 13816:1997

INTERNATIONAL ISOAEC
STANDARD 13816
First edition
1997-05-01
Information technology - Programming
languages, their environments and system
software interfaces - Programming
language ISLISP
Langages de programmation, leurs
Technologies de /‘information -
environnements et interfaces systkme - Langage de programmation
ISLISP
Reference number
ISOAEC 13816:1997(E)
ISO/IEC 13816: 1997(E)
Contents
I Scope, Conventions and Compliance I
1.1 Scope .
1.2 Normative References .
Notation and Conventions . 1
1.3
Lexemes. . 4
1.4
1.4.1 Separators. . 5
1.4.2 Comments. . 5
Textual Representation . 5
1.5
Reserved Identifiers .
1.6 6
Definitions. . 6
1.7
Errors . 9
1.8
1.8.1 Classes of error specification . 9
.............................. 9
1.8.2 Pervasive Error Types
1.9 Compliance of ISLISP Processors and Text .
2 Classes 10
2.1 Metaclasses .
2.2 Predefined Classes . 13
2.3 Standard Classes . 14
2.3.1 Slots . 14
.......................... 14
2.3.2 Creating Instances of Classes
3 Scope and Extent 14
3.1 The Lexical Principle . 15
3.2 Scope of Identifiers . 15
................................ 15
3.3 Some Specific Scope Rules
........................................... 16
3.4 Extent
4 Forms and Evaluation
4.1 Forms . 17
4.2 Function Application Forms . 18
4.3 Special Forms . 18
4.4 Defining Forms . 19
4.5 Macro Forms . 19
4.6 The Evaluation Model . 19
4.7 Functions . 20
4.8 Defining Operators .
0 ISO/IEC 1997
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any
means, electronic or mechanical, including photocopying and microfilm, without permission in writing from the publisher.
ISO/IEC Copyright Office * Case postale 56 0 CI-I-12% 1 Gekve 20 0 Switzerland
Printed in Switzerland
ii
0 ISO/IEC ISO/IEC 13816:1997(E)
5 Predicates
5.1 Boolean Values 26
......................................
5.2 Class Predicates 26
.....................................
5.3 Equality 26
..........................................
5.4 Logical Connectives 29
...................................
6 Control Structure
6.1 Constants
.........................................
6.2 Variables
.........................................
6.3 Dynamic Variables 35
....................................
6.4 Conditional Expressions 36
.................................
6.5 Sequencing Forms 38
....................................
6.6 Iteration 39
..........................................
6.7 Non-Local Exits
.....................................
6.7.1 Establishing and Invoking Non-Local Exits 40
..................
6.7.2 Assuring Data Consistency during Non-Local Exits . 44
7 Objects 45
7.1 Defining Classes 45
.....................................
7.1.1 Determining the Class Precedence List .
7.1.2 Accessing Slots .
7.1.3 Inheritance of Slots and Slot Options .
7.2 Generic Functions .
7.2.1 Defining Generic Functions .
7.2.2 Defining Methods for Generic Functions .
7.2.2.1 Agreement on Parameter Specializers and Qualifiers . 53
7.2.2.2 Congruent Lambda-Lists for all Methods of a Generic Function . . 53
7.2.3 Inheritance of Methods 53
.............................
7.3 Calling Generic Functions 53
................................
7.3.1 Selecting the Applicable Methods . 54
7.3.2 Sorting the Applicable Methods . 54
7.3.3 Applying Methods 55
................................
7.3.3.1 Simple Method Combination . 55
7.3.3.2 Standard Method Combination . 55
7.3.4 Calling More General Methods .
7.4 Object Creation and Initialization .
7.4.1 Initialize-Object .
7.5 Class Enquiry 59
.......................................
8 Macros
9 Declarations and Coercions
10 Symbol class 63
10.1 Symbol Names 63
......................................
10.1.1 Notation for Symbols 64
..............................
10.1.2 Alphabetic Case in Symbol Names 64
.......................
10.1.3 niland 0 .
10.2 Symbol Properties 65
....................................
10.3 Unnamed Symbols 66
....................................
11 Number class 67
ll.lNumberclass. .
.-* 76
11.2 Float class. . .
11.3 Integer class .
..O
0 ISOIIEC
12 Character class
13 List class
13.1Cons . . . . . . . . . . . . . . . . . . . . . + . . . . . . . . . . . . . . . . . . . . .
13.2Nullclass . . . . . . . . . . . .-.-.=.-. . . . . . . . . . . . . . . . . . . . .
13.3 List operations . . . . . . . l . . l l . l . l l . . . . . . . . . . . . . . . . . . . . .
14 Arrays
14.1 Array Classes . . . . . . . . . . . . . . l . . . . . . . . . . . . . . . . . . . . . . . .
14.2 General Arrays . . . . . . . . . . . . . l . . . . . . . . . . . . . . . . . . . . . . . .
14.3 Array Operations . . . . . . . . . l l . l . . . . . . . . . . . . . . . . . . . . . . . .
15 Vectors
16 String class
17 Sequence Functions
18 Stream class
18.1 Streams to Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.2 Other Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19 Input and Output
19.1 Argument Conventions for Input Functions . . . . . . . . . . . . . . . . . . . . . .
19.2 Character I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.3 Binary I/O .
20 Files
21 Condition System
21.1 Conditions. .
...........................
21.2 Signaling and Handling Conditions
..................
21.2.1 Operations relating to Condition Signaling
..................
21.2.2 Operations relating to Condition Handling
........................
21.3 Data associated with Condition Classes
21.3.1 Arithmetic Errors .
21.3.2 Domain Errors .
...................................
21.3.3 Parse Errors
...................................
21.3.4 Simple Errors
..................................
21.3.5 Stream Errors.
.............................
21.3.6 Undefined Entity Errors
21.4 Error Identification .
22 Miscellaneous
Index
iv
0 ISOIIEC
Foreword
IS0 (the International Organization for Standardization) and IEC (the International
Electrotechnical Commission) form the specialized system for worldwide standardization.
National bodies that are members of IS0 or IEC participate in the development of International
Standards through technical committees established by the respective organization to deal with
particular fields of technical activity. IS0 and IEC technical committees collaborate in fields of
mutual interest. Other international organizations, governmental and non-governmental, in
liaison with IS0 and IEC, also take part in the work.
In the field of information technology, IS0 and IEC have established a joint technical
committee, ISOlIEC JTC 1. Draft International Standards adopted by the joint technical
committee are circulated to national bodies for voting. Publication as an International Standard
requires approval by at least 75 % of the national bodies casting a vote.
International Standard ISO/IEC 13816 was prepared by Joint Technical Committee
ISO/IEC JTC 1, Information technology, Subcommittee SC 22, Programming languages, their
environments and system software interfaces.

@ ISO/IEC
Introduction
The programming language ISLISP is a member of the LISP family. It is the result of
standardization efforts by ISO/IEC JTC l/SC 22/WG 16.
The following factors influenced the establishment of design goals for ISLISP:
1. A desire of the international LISP community to standardize on those features of LISP upon
which there is widespread agreement.
2. The existence of the incompatible dialects COMMON-LISP, EULISP, LE-LISP, and SCHEME
(mentioned in alphabetical order).
3. A desire to affirm LISP as an industrial language.
This led to the following design goals for ISLISP:
1. ISLISP shall be compatible with existing LISP dialects where feasible.
2. ISLISP shall have as a primary goal to provide basic functionality.
3. ISLISP shall be object-oriented.
4. ISLISP shall be designed with extensibility in mind.
5. ISLISP shall give priority to industrial needs over academic needs.
6. ISLISP shall promote efficient implementations and applications,
ISO/IEC JTC l/SC 22/WG 16 wishes to thank the many specialists who contributed to this
International Standard.
Vl
INTERNATIONAL STANDARD @ ISO/IEC
Programming languages, their
Information technology -
environments and system software interfaces -
Programming language ISLISP
1.1 Scope
1. Positive Scope
This International Standard specifies syntax and semantics of the computer programming
language ISLISP by specifying requirements for a conforming ISLISP processor and a
conforming ISLISP text.
2. Negative Scope
This International Standard does not specify:
(a) the size or complexity of an ISLISP text that exceeds the capacity of any specific data
processing system or the capacity of a particular processor, nor the actions to be
taken when the corresponding limits are exceeded;
(b) the minimal requirements of a data processing system that is capable of supporting an
implementation of a processor for ISLISP;
(c) the method of preparation of an ISLISP text for execution and the method of
activation of this ISLISP text, prepared for execution;
(d) the typographical presentation of an ISLISP text published for human reading.
(e) extensions that might or might not be provided by the implementation.
1.2 Normative References
The following standards contain provisions which, through reference in this text, constitute
provisions of this International Standard. At the time of publication, the editions indicated were
valid. All standards are subject to revision, and parties to agreements based on this
International Standard are encouraged to investigate the possibility of applying the most recent
editions of the standards indicated below. Members of IEC and IS0 maintain registers of
currently valid International Standards.
l ISO/IEC TR 10034: 1990, Guidelines for the preparation of conformity clauses in
programming language standards.
l IEEE standard 754-1985. IEEE standard for Binary floating point arithmetic. IEEE, New
York, 1985.
1.3 Notation and Conventions
For a clear definition of, and a distinction between, syntactic and semantic concepts, several
levels of description abstraction are used in the following.
@ ISO/IEC
There is a correspondence from ISLISP textual units to their ISLISP data structure
representations. Throughout this International Standard the text and the corresponding ISLISP
objects (data structures) are addressed simultaneously. ISLISP text can be seen as an external
specification of ISLISP data structures. To distinguish between the two representations different
concepts are used. When textual representation is discussed, textual elements (such as
identifiers, liter&, and compound forms) are used; when ISLISP objects are discussed, objects
(such as symbols and lists) are used.
The constituents of ISLISP text are called forms. A form can be an identifier, a ZiteraZ, or a
compound form. A compound form can be a function application form, a macro form, a special
form, or a defining form.
An identifier is represented by a symbol. A compound form is represented by a non-null list. A
literal represents neither a symbol nor a list, and so is neither an identifier nor a compound form;
for example, a number is a literal.
An object is prepared for execution; this might include transformation or compilation,
including macro expansion. The method of preparation for execution and its result are not
defined in this International Standard (with exception of the violations to be detected). After
successful preparation for execution the result is ready for execution. The combination of
preparation for execution and subsequent execution implements ISLISP’s evaluation model.
The term “evaluation” is used because ISLISP is an expression language-each form has a value
which is used to compute the value of the containing form. The results obtained when an entity
is prepared for execution are designated throughout this International Standard by the
construction “prepared entity” ; e.g., “prepared form,” “prepared special form.”
Example: A “cond special form” becomes a “prepared cond” by preparation for execution.
In the examples, the metasymbol “9 designates the result of an actual evaluation. For example:
(+ 3 4) * 7
The metasymbol “4’ identifies the class that results from the evaluation of a form having a
given pattern. For example:
(+ il i2) +
Given a form pattern (usually defined by its constant parts, the function name or special
operator), + relates it to the class to which the result of the evaluation of all matching forms
belong.
Form patterns or forms which are equivalent are related by E.
The following notational conventions for form patterns are used:
(f-name argument *) + result-class f kind
In this notation, words written in italics are non-terminal (pattern variables). f-name is always
terminal: Specific function names, special operators, defining form names, or generic function
names are always presented.
@ ISO/IEC
An underlined term (like the name in a defining form) in this notation, indicates an expression
that is not evaluated. If a form might or might not be evaluated (like one of the then-form or
else-form in an if ), this is indicated explicitly in the text.
uniform .ly denoted as follows: Cl ass names are is the name
spoken aloud as “list class.”
of a class; th .is is usually
Note: note-text, in this International Standard
Notes, ap pearing as have no effect on the
language. They are for better understanding by the human reader.
Regarding the pattern variables and the extensions of above, the following conventions are also
adopted:
term+ denotes one or more occurrences of term;
term* denotes zero or more occurrences of term;
[term] denotes at most one occurrence of term, commonly one says that term
is optional;
(term1 term2 . . . denotes grouping of terms.
term1 1 term2 1 . . . denotes grouping of alternative terms.
The following naming conventions are used to denote forms values obey the respective
class restrictions:
array, arrayl, . . . tHTa?Jj, . . .

cons, consl, . . . CO?lSj, . . .
list, listl, . . . liStj, . . .
obj, objl, . . . objj, . . .
sequence, sequencel, . . . sequencej, . . . or (see 517)
stream, streaml, . . . streamj, . . . (stream)
string, stringl, . . . Stringj, . . .
char, charl, . . . charj, . . .
function, functionl, . . . fU?2CtiO?2j, . . .
class, classI, . . . ClaSSj , - l l
symbol, symboll, . . . symbolj, l l .
2, Xl, . . l Xj, l l l
X, Xl, . .Xj. l -b
In this International Standard the conventions detailed below are used, except where noted:

@ ISO/IEC
-p Predicates- sometimes called “boolean functions”-usually have names that end in a -p.
Usually every class has a characteristic function, whose name is built as name-p if
name is hyphenated (generic-function-p), or namep if name is not hyphenated
(symbolp). Note that not all functions whose names end with “p” are predicates.
treat e- Usually a built-in class has a constructor function, which is called create-name.
def This is used as the prefix of the defining operators.
set-name are writers for a place,
set- Within this International Standard, any functions named
for which there is a corresponding reader named name.
For any kind of entity in the language, the phrase “entity-kind name” refers to the entity of kind
entity-kind denoted by name. For example, the phrases “function name,” “constant name,” or
“class name” respectively mean the function, constant, or class denoted by name.
1.4
Lexemes
An ISLISP text is built up from lexemes. Lexemes are built up from at least the following
characters (see 512):
ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz
0123456789+-<>/*&=.?-!$%:@[I-{)-#
Additional characters are implementation defined.
The following characters are individual lexemes (see $13.1 and $8):
The following character tuples (where n is a sequence of digits) are individual lexemes (see $4.7,
$8, and $14.1):
#j #( , @ #B #b #0 #o #X #x #na #nA
The textual representations of symbols (see $10) numbers (see $11) characters (see $12) and
strings (see 516) are lexemes.
\ (single escape) and 1 ( multiple escape) are special characters. They may occur in some
lexemes (identifiers and string literals).
0 t her lexemes are separated by delimiters. Delimiters are separators along with the following
characters:
The effect of delimiting is disestablished inside a string (see $16)
or inside a corresponding pair
of multiple escape characters (see $10) or for the character immediately following #\.
@ ISO/IEC
1.4.1 Separators
Separators are as follows: blank, comments, newline, and an implementation-defined set of
characters, (e.g., tabs). Separators have no meaning and can be replaced by each other without
changing the meaning of the ISLISP text.
1.4.2 Comments
The character semicolon (;) is the comment begin character. That is, the semicolon and all the
characters up to and including the end-of-line form a comment.
A character sequence beginning with # I and ending with I # is a comment. Such comments may
be nested.
Being a separator, a comment cannot occur inside a lexeme.
1.5 Textual Representation
The textual representation of an object is machine independent. The following are some of the
textual representations of the ISLISP objects. This representation is readable by the read
function. Lexemes are described in 5 1.4
is the only object whose class is
Null The object nil . Upon input, it may be written as
implementation defined whether
nil It is nil prints as nil or ().
or 0.
List Proper lists are those lists terminated by nil. Usually they are denoted as (objl objz
. . . ubj, ) . A dotted list (i. e., a list whose last tail is not nil) appears as ( objl objz . . . obj,
.
obj,+1) ’
Character An instance of the class is represented by #\?, where “?” is the character in
question. There are two special standard characters that are not represented in this way,
namely newline and space, whose representations are #\newline and #\space, respectively.
cdr), where the car and cdr are objects.
Cons A cons is expressed as (car .
Integer An integer (radix 10) is represented as a sequence of digits optionally preceded by a + or -
sign. If the number is represented in binary radix (or in octal or hexadecimal) then the
textual representation is preceded by #b (or #o or #x, respectively).
Float A floating point number is written in one of the following formats:
[s]dd.d.dd.d
[s]dd. .d.dd.dE[s]dd.d
[s]dd.d.dd.de[s]dd. .d
[sldd. .dE[s]dd. .d
[s]dd. .de[s]dd. .d
where s is either “+” or “-‘I, and d is one of “0’‘-“9”. For example: 987.12, +12.5E-13,
-1.5E12, lE32l.
1 This number, alth .ough belonging to the set of natural numbers, usually is considered as only a floating point
representation.
number because of its
Vector A vector of class is written as #(objl . . . obj,) .
An array of class or can be written on input as #na
Array
(where n is an integer indicating the number of dimensions of the array) followed by a
nested structure of sequences denoting the contents of the array. This structure is defined
as follows. If n = 1 the structure is simply (objl . . . o bjn > . If n > 1 and the dimensions
are 721 722 . . . , the structure is (sty . . . str,, >, where the stri are the structures of the nl
subarrays, each of which has dimensions (n2 . . . >. As an example, the representation of
’ (2 3 4) 5) is as follows:
(treat e-array
#3a(((5 5 5 5) (5 5 5 5) (5 5 5 5)) ((5 5 5 5) (5 5 5 5) (5 5 5 5))).
will be printed using #( . . .
>
On output (see format), arrays of class
notation.
String A string is represented by the sequence of its characters enclosed in a pair of “‘s. For
Special characters are preceded with a backslash as an escape character.
example: “abc”.
Symbol A named symbol is represented by its print name. Vertical bars (I) might need to enclose
the symbol if it contains certain special characters; see $10. The notation, if any, used for
unnamed symbols is implementation defined.
There are objects which do not have a textual representation, such as a class or an instance of
the class.
1.6 Reserved Identifiers
or an ampersan d not be
Symbols whose names contain a colon ( :) (a) are reser mved and may
.
start with colon . are c alled keywords.
used as identifiers. Symbols whose names
( >
1.7 Definitions
For the purposes of this International Standard, the following definitions apply:
1.7.1 abstract class: A class that by definition has no direct instances.
1.7.2 activation: Computation of a function. Every activation has an activation point, an
activation period, and an activation end. The activator, which is a function application
form prepared for execution, starts the activation at the activation point.
1.7.3 accessor: Association of a reader and a writer for a slot of an instance.
1.7.4 binding: Binding has both a syntactic and a semantic aspect.
Syntactically, “binding” describes the relation between an identifier and a binding ISLISP
form. The property of being bound can be checked textually by relating defining and
applied identifier occurrences.
Semantically, “binding” describes the relation between a variable, its denoting identifier,
and an object (or, the relation between a variable and a location). This relation might be
imagined to be materialized in some entity, the binding. Such a binding entity is
constructed at run time and destroyed later, or might have indefinite extent.
1.7.5 class: Object, that determines the structure and behavior of a set of other objects, called
its instances. The behavior is the set of operations that can be performed on an instance.
@ ISO/IEC ISO/IEC 13816:1997(E)
1.7.6 condition: An object that represents a situation that has been (or might be) detected by
a running program.
1.7.7 definition point: An identifier represents an ISLISP object starting with its definition
point, which is a textual point of an ISLISP text.
1.7.8 direct instance: Every ISLISP object is direct instance of exactly one class, which is called
“its class” . The set of all direct instances together with their behavior constitute a class.
effect that is determined only through
1.7.9 dynamic: Having an program execution and that
be determined statically.
cannot, in general,
1.7.10 dynamic variable: A variable whose associated binding is determined by the most
recently executed active block that established it, rather than statically by a lexically
apparent block according to the lexical principle.
1.7.11 evaluation: Computation of a form prepared for execution which results in a value and/or
a side effect.
1.7.12 execution: A sequence of (sometimes nested) activations.
1.7.13 extension: An implementation-defined modification to the requirements of this
International Standard that does not invalidate any ISLISP text complying with this
International Standard (except by prohibiting the use of one or more particular spellings of
identifiers), does not alter the set of actions which are required to signal errors, and does
not alter the status of any feature designated as implementation dependent.
1.7.14 form: A single, syntactically valid unit of program text, capable of being prepared for
execution.
1.7.15 function: An ISLISP object that is called with arguments, performs a computation
(possibly having side-effects), and returns a value.
determined by the classes of
1.7.16 generic function: Function whose application behavior is
-
of several methods.
the values of its arguments and which consists - in general
1.7.17 identifier: A lexical element (lexeme) which designates an ISLISP object. In the data
structure representation of ISLISP texts, identifiers are denoted by symbols.
1.7.18 immutable binding: A binding is immutable if the relation between an identifier and the
object represented by this identifier cannot be changed. It is a violation if there is attempt
to change an immutable binding (error-id. immutable-binding).
1.7.19 immutable object: An object is immutable if it is not subject to change, either because
no operator is provided that is capable of effecting such change, or because some constraint
exists which prohibits the use of an operator that might otherwise be capable of effecting
such a change. Except as explicitly indicated otherwise, a conforming processor is not
required to detect attempts to modify immutable objects; the consequences are undefined
if an attempt is made to modify an immutable object.
1.7.20 implementation defined: A feature, possibly differing between different ISLISP
processors, but completely defined for every processor.
1.7.21 implementation dependent: A feature, possibly differing between different ISLISP
processors, but not necessarily defined for any particular processor.
Note: A conforming ISLISP text must not depend upon implementation-dependent features.
1.7.22 inheritance: Relation between a class and its superclass which maps structure and
behavior of the superclass onto the class. ISLISP supports a restricted form of multiple
inheritance; i.e., a class may have several superclasses at once.

@ ISO/IEC
1.7.23 instance (of a class): Either a direct instance of a class or an instance of one of its
sub classes.
1.7.24 literal: An object whose representation occurs directly in a program as a constant value.
17.25 metaclass: A class whose instances are themselves classes.
1.7.26 method: Case of a generic function for a particular parameter profile, which defines the
class-specific behavior and operations of the generic function.
1.7.27 object: An object is anything that can be created, destroyed, manipulated, compared,
stored, input, or output by the ISLISP processor. In particular, functions are ISLISP objects.
Objects that can be passed as arguments to functions, can be returned as values, can be
bound to variables, and can be part of structures, are called first-class objects.
1.7.28 operator: the first element of a compound form, which is either a reserved name that
identifies the form as a special form, or the name of a macro, or a lambda expression, or
else an identifier in the function namespace.
1.729 parameter profile: Parameter list of a method, where each formal parameter is
accompanied by its class name. If a parameter is not accompanied by a class name, it
belongs to the most general class.
1.7.30 place: Objects can be stored in places and retrieved later. Places are designated by forms
which are permitted as the first argument of setf. If used this way an object is stored in
the place. If the form is not used as first argument of setf the stored object is retrieved.
The cases are listed in the description of setf.
1.7.31 position:
(a) argument position: Occurrence of a text unit as an element in a form excluding the
first one.
(b) operator position: Occurrence of a text unit as the first element in a form.
process: The execution of an ISLISP text prepared for execution.
1.7.32
processor: A system or mechanism, that accepts an ISLISP text (or an equivalent data
1.7.33
structure) as input, prepares it for execution, and executes the result to produce values and
side effects.
1.7.34 program: An aggregation of expressions to be evaluated, the specific nature of which
depends on context. Within this International Standard, the term “program” is used only
in an abstract way; there is no specific syntactic construct that delineates a program.
scope: The scope of an identifier is that textual part of a program where the meaning of
1.7.35
that identifier is defined; i.e., there exists an ISLISP object designated by this identifier.
1.7.36 slot: A named component of an instance which can be accessed using the slot accessors.
The structure of an instance is defined by the set of its slots.
1.7.37 text: A text that complies with the requirements of this International Standard (i.e., with
the syntax and static semantics of ISLISP). An ISLISP text consists of a sequence of toplevel
forms.
1.7.38
toplevel form: Any form that either is not nested in any other form or is nested only in
progn forms.
1.7.39 toplevel scope: The scope in which a complete ISLISP text unit is processed.
1.7.40
writer: A method associated with a slot of a class, whose task is to bind a value with a
slot of an instance of that class.
@ ISO/IEC ISO/IEC 13816:1997(E)
1.8 Errors
An error is a situation arising during execution in which the processor is unable to continue
correct execution according to the semantics defined in this International Standard. The act of
detecting and reporting such an error is called signaling the error.
A violation is a situation arising during preparation for execution in which the textual
requirements of this International Standard are not met. A violation shall be detected during
preparation for execution.
1.8.1 Classes of error specification
The wording of error specification in this International Standard is as follows:
(a) “an error shall be signaled”
An implementation shall detect an error of this kind no later than the completion of
execution of the form having the error, but might detect them sooner (e.g., when the code
is being prepared for execution).
Evaluation of the current expression shall stop. It is implementation defined whether the
entire running process exits, a debugger is entered, or control is transferred elsewhere
within the process.
(b) “the consequences are undefined”
This means that the consequences are unpredictable. The consequences may range from
harmless to fatal. No conforming ISLISP text may depend on the results or effects. A
conforming ISLISP text must treat the consequences as unpredictable. In places where
“must, ” “must not ,” or “may not” are used, then this is equivalent to stating that “the
consequences are undefined” if the stated requirement is not met and no specific
consequence is explicitly stated. An implementation is permitted to signal an error in this
case.
For indexing and cross-referencing convenience, errors in this International Standard have an
associated error identification label, notated by text such as “(error-id. sample).” The text of
these labels has no formal significance to ISLISP texts or processors; the actual class of any
object which might be used by the implementation to represent the error and the text of any
error message that might be displayed is implementation dependent.
1.8.2 Pervasive Error Types
Most errors are described in detail in the contect in which they occur. Some error types are so
pervasive that their detailed descriptions are consolidated here rather than repeated in full detail
upon each occurrence.
1. Domain error: an error shall be signaled if the object given as argument of a standard
function for which a class restriction is in effect is not an instance of the class which is
required in the definition of the function (error-id. domain-error).

@ ISO/IEC
2. Arity error: an error shall be signaled if a function is activated with a number of
arguments which is different than the number of parameters as required in the function
definition (error-id. unity-error).
3. Undefined entity error: an error shall be signaled if the entity denoted by an identifier does
not exist when a reference to that entity is made (error-id. undefined-entity). Two
commonly occuring examples of this type of error are undefined-function and
unbound-variable.
This list does not exhaust the space of error types. For a more complete list, see 521.4.
1.9 Compliance of ISLISP Processors and Text
An ISLISP processor complying with the requirements of this International Standard shall
(a) accept and implement all features of ISLISP specified in this International Standard.
(b) reject any text that contains any textual usage which this International Standard explicitly
defines to be a violation (see 5 1.8).
(c) be accompanied by a document that provides the definitions of all implementation-defined
features.
(d) be accompanied by a document that separately describes any features accepted by the
processor that are not specified in this International Standard; these extensions shall be
described as being “extensions to ISLISP as specified by ISO/IEC 13816:1997(E).”
A complying ISLISP text shall not rely on implementation-dependent features. However, a
complying ISLISP text may rely on implementation-defined features required by this
International Standard.
A complying ISLISP text shall not attempt to create a lexical variable binding for any named
constant defined in this International Standard. It is a violation if any such attempt is made.
2 Classes
In ISLISP, data types are covered by the class system. A class is an object that determines the
structure and behavior of a set of other objects, which are called its instances. Every ISLISP
object is an instance of a class. The behavior is the set of operations that can be performed on
an instance.
A class can inherit structure and behavior from other classes. A class whose definition refers to
other classes for the purpose of inheriting from them is said to be a subclass of each of those
classes. The classes that are designated for purposes of inheritance are said to be superclasses
of the inheriting class.
A class can be named by an identifier. For example, this identifier can be used as a parameter
specializer in method definitions. The class special form can be used to refer to access the class
object corresponding to its name.
@ ISO/IEC
A class Cr is a direct superclass of a class C2 if C2 explicitly designates Cr as a superclass in
its definition, or if Cl is defined by this International Standard to be a direct superclass of C2
(for example, by indenting C2 under Cl in Figure 1). In this case C2 is a direct subclass of Cr.
A class Cn is a superclass of a class Cl if there exists a series of classes C2, . . . , Cn-l such that
C i+l is a direct superclass of Ci for 1 < i < n. In this case, Cr is a subclass of Cn. A class is
considered neither a superclass nor a subclass of itself. That is, if Cr is a superclass of Cz, then
Cl # C2. The set of classes consisting of some given class C along with all of its superclasses is
called “C and its superclasses.”
If a user-defined class C inherits from two classes, Cl and C2, the only superclasses that Cl and
C2 may have in common are or . This allows a restricted form of
multiple inheritance.
Every ISLISP object is a direct instance of exactly one class which is called “its” class.
An instance of a class is either a direct instance of that class or an instance of one of its
subclasses.
Classes are organized into a directed acyclic graph defined by the subclass relation. The
nodes are classes and there is an edge from Ci to C’s iff Cr is direct subclass of C2. This graph is
called the inheritance graph. It has as root the class , the only class with no superclass.
Therefore it is the superclass of every class except itself. The class named is
an instance of the class and is a superclass of every class that is an instance
of except itself.
Each class has a class precedence list, which is a total ordering on the set of the given class
and its superclasses. The total ordering is expressed as a list ordered from most specific to least
specific. The class precedence list is used in several ways. In general, more specific classes can
shadow, or override, features that would otherwise be inherited from less specific classes. The
method selection and combination process uses the class precedence list to order methods from
most specific to least specific.
2.1 Metaclasses
Classes are represented by objects that are themselves instances of classes. The class of the class
of an object is termed the metaclass of that object. The term metuclass is used to refer to a
class that has instances that are themselves classes.
by the classes that are its instances
The metaclass determines the form of inheritance used and
of those classes.
the representation of the instances
The ISLISP Object System provides the following predefined metaclasses:
l The class is the default class of classes defined by defclass.
l The class is the class whose instances are classes that have special
implementations or restricted capabilities. For example, it is not possible to define
subclasses of a built-in class.














;; Note: also inherits from

















(stream-error)






;; Note: also inherits from
Subclasses appear indented under superclasses.
Figure 1. Class Inheritance
@ ISO/IEC ISO/IEC 13816:1997(E)
2.2 Predefined Classes
The following classes are primitive classes in the class system (i.e., predefined classes that are
not met aclasses) :








Xint eger>
(stream-error)






Xobj ect>


Xundef ined-f unct ion>




The classes and are predefined metaclasses.
A user-defined class, defined by def class, must be implemented as an instance of
. A predefined class can be implemented either as an instance of
(as if defined by defclass) or as an instance of or as an
instance of .
Figure 1 shows the required inheritance relationships among the classes defined by ISLISP. For
each pair of classes Cl and C2 in this figure, if Cl is linked directly by an arrow to C2, Cl is a
direct superclass of C2 (and C2 is a direct subclass of Cl). Additional relationships might exist,
subject to the following constraints:
It is implementation defined whether is a subclass of the
class .
Except as described in Figure 1 and the above constraint on
, no other subclass relationships exist among the classes
defined in this International Standard. However, additional implementation-specific
subclass relationships may exist between implementation-specific classes and classes
defined in this International Standard.
The class precedence list for observes the partial order , , ,
.
Users may define additional classes using def class.
A built-in class is one whose instances have restricted capabilities or special representations. The
def class defining form must not be used to define subclasses of a built-in class. An error shall
be signaled if create is called to create an instance of a built-in class.
A standard class is an instance of , and a built-in class is an instance of
.
A standard class defined with no direct superclasses is guaranteed to be disjoint from all of the
classes in the figure, except for the classes named and The class is the class of all functions. The class is
the default class of all generic functions.
2.3 Standard Classes
2.3.1 Slots
An object that has as its metaclass has zero or more named slots. The slots
of an object are determined by the class of the object. Each slot can hold one object as its value.
The name of a slot is an identifier.
be unbound. The consequences are
When a slot does not have a value, the slot is said to
undefined if an attempt is made to retrieve the value of an unbound slot.
Storing and retrieving the value of a slot is done by generic functions defined by the def class
defining form.
All slots are local; i.e., there are no shared slots accessible by several instances.
A class is said to define a slot with a given name when the def class defining form for that
class contains a slot specifier with that name. Defining a slot does not immediately create a slot;
it causes a slot to be created each time an instance of the class is created.
A slot i
...