ISO/IEC 13816:2007

INTERNATIONAL ISO/IEC
STANDARD 13816
Second edition
2007-10-01
Information technology — Programming
languages, their environments and
system software interfaces —
Programming language ISLISP
Technologies de l'information — Langages de programmation, leurs
environnements et interfaces de logiciel système — Langage de
programmation ISLISP
Reference number
©
ISO/IEC 2007
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO/IEC 2007
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 either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2007 – All rights reserved

Contents
1Scope 1
2 Normative references 1
3 Compliance of ISLisp processors and text 2
4 Terms and definitions 2
5 Notation and conventions 7
6 Lexemes 9
6.1 Separators. . . . . . . . . . . . . . . . . . 10
6.2 Comments. . . . . . . . . . . . . . . . . . 10
7 Textual representation 10
8 Reserved identifiers 11
9 Errors 11
9.1 Classesoferrorspecification. . . . . . . . . . . . . . 12
9.2 Pervasiveerrortypes . . . . . . . . . . . . . . . 12
10 Classes 13
10.1 Metaclasses . . . . . . . . . . . . . . . . . . 13
10.2 Predefinedclasses. . . . . . . . . . . . . . . . . . . . . . 15
10.3 Standardclasses . . . . . . . . . . . . . . . . 16
10.3.1 Slots . . . . . . . . . . . . . . . . . . . . . . . 16
10.3.2 Creatinginstancesofclasses. . . . . . . . . . . . 16
11 Scope and extent 17
11.1 Thelexicalprinciple . . . . . . . . . . . . . . . 17
11.2 Scopeofidentifiers . . . . . . . . . . . . . . . . 17
11.3 Somespecificscoperules. . . . . . . . . . . . . . . 18
11.4 Extent. . . . . . . . . . . . . . . . . . . . . . . . . 18
12 Forms and evaluation 19
12.1 Forms . . . . . . . . . . . . . . . . . . . 19
12.2 Functionapplicationforms . . . . . . . . . . . . . . 20
12.3 Specialforms . . . . . . . . . . . . . . . . . 20
12.4 Definingforms . . . . . . . . . . . . . . . . . 21
12.5 Macroforms. . . . . . . . . . . . . . . . . . 21
12.6 Theevaluationmodel . . . . . . . . . . . . . . . 21
12.7 Functions . . . . . . . . . . . . . . . . . . . . . . . . 22
12.8 Definingoperators . . . . . . . . . . . . . . . . 26
13 Predicates 28
13.1 Booleanvalues . . . . . . . . . . . . . . . . . 28
13.2 Classpredicates. . . . . . . . . . . . . . . . . . . . . . 28
13.3 Equality. . . . . . . . . . . . . . . . . . 29
13.4 Logicalconnectives . . . . . . . . . . . . . . . . 31
14 Control structure 33
14.1 Constants . . . . . . . . . . . . . . . . . . 33
14.2 Variables . . . . . . . . . . . . . . . . . . 34
c
� ISO/IEC 2007 – All rights reserved iii

14.3 Dynamicvariables . . . . . . . . . . . . . . . . 37
14.4 Conditionalexpressions . . . . . . . . . . . . . . . 38
14.5 Sequencingforms . . . . . . . . . . . . . . . . 40
14.6 Iteration. . . . . . . . . . . . . . . . . . 41
14.7 Non-localexits . . . . . . . . . . . . . . . . . 42
14.7.1 Establishing and invoking non-local exits . . . . . . . . . . . . . . . . . . . 42
14.7.2 Assuring data consistency during non-local exits . . . . . . . . . . . . . . . 46
15 Objects 47
15.1 Definingclasses . . . . . . . . . . . . . . . . . 47
15.1.1 Determining the class precedence list . . . . . . . . . . . . . . . . . . . . . . 50
15.1.2 Accessingslots . . . . . . . . . . . . . . . 51
15.1.3 Inheritanceofslotsandslotoptions . . . . . . . . . . 51
15.2 Genericfunctions . . . . . . . . . . . . . . . . 52
15.2.1 Defininggenericfunctions . . . . . . . . . . . . 52
15.2.2 Definingmethodsforgenericfunctions . . . . . . . . . 54
15.2.2.1 Agreement on parameter specializersandqualifiers. . . . 55
15.2.2.2 Congruent lambda-lists for all methods of a generic function . . . 55
15.2.3 Inheritanceofmethods. . . . . . . . . . . . . 55
15.3 Calling generic functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
15.3.1 Selectingtheapplicablemethods . . . . . . . . . . . . . . 56
15.3.2 Sortingtheapplicablemethods . . . . . . . . . . . 56
15.3.3 Applyingmethods . . . . . . . . . . . . . . . . . . . 57
15.3.3.1 Simple method combination . . . . . . . . . . . . . . . . . . . . . 57
15.3.3.2 Standard method combination . . . . . . . . . . . . . . . . . . . . 57
15.3.4 Calling more general methods . . . . . . . . . . . . . . . . . . . . . . . . . . 59
15.4 Objectcreationandinitialization . . . . . . . . . . . . 60
15.4.1 Initialize-object. . . . . . . . . . . . . . . 60
15.5 Classenquiry . . . . . . . . . . . . . . . . . 61
16 Macros 61
17 Declarations and coercions 63
18 Symbol class 65
18.1 Symbolnames . . . . . . . . . . . . . . . . . 65
18.1.1 Notation for symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
18.1.2 Alphabeticcaseinsymbolnames . . . . . . . . . . . 66
18.1.3 nil and () . . . . . . . . . . . . . . . . . . . . . 67
18.2 Symbolproperties . . . . . . . . . . . . . . . . 67
18.3 Unnamedsymbols . . . . . . . . . . . . . . . . 68
19 Number class 68
19.1 Numberclass . . . . . . . . . . . . . . . . . 69
19.2 Floatclass. . . . . . . . . . . . . . . . . . . . . . . . 77
19.3 Integerclass. . . . . . . . . . . . . . . . . . 80
20 Character class 83
21 List class 84
21.1 Cons . . . . . . . . . . . . . . . . . . . 84
21.2 Nullclass . . . . . . . . . . . . . . . . . . 87
21.3 Listoperations . . . . . . . . . . . . . . . . . 87
22 Arrays 91
c
iv � ISO/IEC 2007 – All rights reserved

22.1 Arrayclasses . . . . . . . . . . . . . . . . . 91
22.2 Generalarrays . . . . . . . . . . . . . . . . . 92
22.3 Arrayoperations . . . . . . . . . . . . . . . . 93
23 Vectors 95
24 String class 96
25 Sequence functions 99
26 Stream class 102
26.1 Streamstofiles . . . . . . . . . . . . . . . . . 103
26.2 Otherstreams. . . . . . . . . . . . . . . . . 105
27 Input and output 107
27.1 Argument conventions for input functions . . . . . . . . . . . . . . . . . . . . . . . 107
27.2 CharacterI/O . . . . . . . . . . . . . . . . . 107
27.3 BinaryI/O . . . . . . . . . . . . . . . . . . . . . . . 111
28 Files 112
29 Condition system 114
29.1 Conditions. . . . . . . . . . . . . . . . . . . . . . . . 115
29.2 Signalingandhandlingconditions. . . . . . . . . . . . 115
29.2.1 Operations relating to condition signaling . . . . . . . . . . . . . . . . . . . 116
29.2.2 Operations relating to condition handling . . . . . . . . . . . . . . . . . . . 117
29.3 Dataassociatedwithconditionclasses . . . . . . . . . . . 118
29.3.1 Arithmeticerrors. . . . . . . . . . . . . . . 118
29.3.2 Domainerrors . . . . . . . . . . . . . . . 118
29.3.3 Parseerrors . . . . . . . . . . . . . . . . 118
29.3.4 Simpleerrors . . . . . . . . . . . . . . . 119
29.3.5 Streamerrors . . . . . . . . . . . . . . . 119
29.3.6 Undefinedentityerrors . . . . . . . . . . . . . 119
29.4 Erroridentification . . . . . . . . . . . . . . . . 120
30 Miscellaneous 122
Index 123
c
� ISO/IEC 2007 – All rights reserved v

Foreword
ISO (the International Organization for Standardization) and IEC (the International
Electrotechnical Commission) form the specialized system for worldwide standardization.
National bodies that are members of ISO 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. ISO and IEC technical committees collaborate in fields of
mutual interest. Other international organizations, governmental and non-governmental, in
liaison with ISO and IEC, also take part in the work. In the field of information technology, ISO
and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC
Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. 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.
Attention is drawn to the possibility that some of the elements of this document may be the
subject of patent rights. ISO and IEC shall not be held responsible for identifying any or all such
patent rights.
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.
This second edition cancels and replaces the first edition (ISO/IEC 13816:1997), which has been
technically revised.
c
vi � ISO/IEC 2007 – All rights reserved

Introduction
The programming language ISLISP is a member of the LISP family.
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.
ISLISP shall give priority to industrial needs over academic needs.
5.
6. ISLISP shall promote efficient implementations and applications.
c
� ISO/IEC 2007 – All rights reserved vii

INTERNATIONAL STANDARD ISO/IEC 13816:2007(E)
Information technology — Programming languages, their
environments and system software interfaces —
Programming language ISLISP
1Scope
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.
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.
2 Normative references
The following referenced documents are indispensable for the application of this document. For
dated references, only the edition cited applies. For undated references, the latest edition of the
referenced document (including any amendments) applies.
• ISO/IEC TR 10034:1990, Guidelines for the preparation of conformity clauses in
programming language standards
• IEEE standard 754-1985. Standard for binary floating point arithmetic
c
� ISO/IEC 2007 – All rights reserved 1

3 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 ISLIS P 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 §9);
(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:2007(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.
4 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
4.1
abstract class
class that by definition has no direct instances
4.2
activation
computation of a function
Note: 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.
4.3
accessor
association of a reader and a writer for a slot of an instance
4.4
argument position
occurrence of a text unit as an element in a form excluding the first one
c
2 � ISO/IEC 2007 – All rights reserved

4.5
binding
concept that has both a syntactic and a semantic aspect, where
• syntactically, “binding” describes the relation between an identifier and a binding ISLISP
form, and
• semantically, “binding” describes the relation between a variable, its denoting identifier,
and an object (or, the relation between a variable and a location)
Note 1: The property of being bound can be checked textually by relating defining and applied
identifier occurrences.
Note 2: Semantically, the binding 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.
4.6
class
object that determines the structure and behavior of a set of other objects called its instances
Note: The behavior is the set of operations that can be performed on an instance.
4.7
condition
object that represents a situation that has been (or might be) detected by a running program
4.8
definition point
textual point of an ISLISP text that is the start of an identifier’s representation of an ISLISP
object
4.9
direct instance
instance of a class but not an instance of one of its subclasses
Note: 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.
4.10
dynamic
having an effect that is determined only through program execution and that cannot, in general,
be determined statically
4.11
dynamic variable
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
4.12
evaluation
computation of a form prepared for execution which results in a value and/or a side-effect
c
� ISO/IEC 2007 – All rights reserved 3

4.13
execution
sequence of (sometimes nested) activations
4.14
extension
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
4.15
form
single, syntactically valid unit of program text, capable of being prepared for execution
4.16
function
ISLISP object that is called with arguments, performs a computation (possibly having
side-effects), and returns a value
4.17
generic function
function whose application behavior is determined by the classes of the values of its arguments
and which consists – in general – of several methods
4.18
identifier
lexical element (lexeme) which designates an ISLISP object
Note: In the data structure representation of ISLISP texts, identifiers are denoted by symbols.
4.19
immutable binding
binding in which the relation between an identifier and the object represented by this identifier
cannot be changed
Note: It is a violation if there is attempt to change an immutable binding (error-id.
immutable-binding).
4.20
immutable object
object which 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
Note: 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.
4.21
implementation defined
feature, possibly differing between different ISLISP processors, but completely defined for every
processor
c
4 � ISO/IEC 2007 – All rights reserved

4.22
implementation dependent
feature, possibly differing between different ISLISP processors, but not necessarily defined for any
particular processor
Note: Aconforming ISLISP text must not depend upon implementation-dependent features.
4.23
inheritance
relation between a class and its superclass which maps structure and behavior of the superclass
onto the class
Note: ISLISP supports a restricted form of multiple inheritance; i.e., a class may have several direct
superclasses at once.
4.24
instance
�class� either a direct instance of a class or an instance of one of its subclasses
4.25
literal
object whose representation occurs directly in a program as a constant value
4.26
metaclass
class whose instances are themselves classes
4.27
method
case of a generic function for a particular parameter profile, which defines the class-specific
behavior and operations of the generic function
4.28
object
anything that can be created, destroyed, manipulated, compared, stored, input, or output by the
ISLISP processor
Note 1: In particular, functions are ISLISP objects.
Note 2: 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.
4.29
operator
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
4.30
operator position
occurrence of a text unit as the first element in a form
c
� ISO/IEC 2007 – All rights reserved 5

4.31
parameter profile
parameter list of a method, where each formal parameter is accompanied by its class name
Note: If a parameter is not accompanied by a class name, it belongs to the most general class.
4.32
place
location where objects can be stored and retrieved later
Note: Places are designated by forms which are permitted as the first argument of setf.Ifusedthis
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.
4.33
process
execution of an ISLISP text prepared for execution
4.34
processor
system or mechanism, that accepts an ISLISP text (or an equivalent data structure) as input,
prepares it for execution, and executes the result to produce values and side-effects
4.35
program
aggregation of expressions to be evaluated, the specific nature of which depends on context
Note: Within this International Standard, the term “program” is used only in an abstract way; there is
no specific syntactic construct that delineates a program.
4.36
scope
�identifier� the textual part of a program where the meaning of that identifier is defined; i.e.,
there exists an ISLISP object designated by this identifier
4.37
slot
named component of an instance which can be accessed using the slot accessors
Note: The structure of an instance is defined by the set of its slots.
4.38
text
text that complies with the requirements of this International Standard (i.e., with the syntax
and static semantics of ISLISP)
Note: An ISLISP text consists of a sequence of toplevel forms.
4.39
toplevel form
any form that either is not nested in any other form or is nested only in progn forms
4.40
toplevel scope
scope in which a complete ISLISP text unit is processed
c
6 � ISO/IEC 2007 – All rights reserved

4.41
writer
method associated with a slot of a class, whose task is to bind a value with a slot of an instance
of that class
5 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.
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, literals,and compound forms) are used; when ISLISP objects are discussed, objects
(such as symbols and lists)areused.
The constituents of ISLISP text are called forms.A form can be an identifier,a literal,ora
compound form.A compound form can be a function application form,a macro form,a special
form,ora defining form.
An identifier is represented by a symbol.A compound form is represented by a non-null list.A
literal is represented by 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 “⇒” designates the result of an actual evaluation. For example:
(+34) ⇒ 7
The metasymbol “→” identifies the class that results from the evaluation of a form having a
given pattern. For example:
(+ i i ) →
1 2
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.
c
� ISO/IEC 2007 – All rights reserved 7

Form patterns or forms which are equivalent are related by ≡.
The following notational conventions for form patterns are used:
(f-name argument*) → result-class fkind
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.
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.
Class names are uniformly denoted as follows: . For example, is the name
of a class; this is usually spoken aloud as “list class.”
Notes, appearing as Note: note-text, in this International Standard 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;
{term term .} denotes grouping of terms.
1 2
term | term | . denotes grouping of alternative terms.
1 2
The following naming conventions are used to denote forms whose arguments obey the respective
class restrictions:
array, array , .array ,.
1 j
cons, cons , .cons ,.
1 j
list, list , .list ,.
1 j
obj, obj , .obj ,.
1 j
sequence, sequence ,.sequence ,. or (see §25)
1 j
stream, stream ,.stream ,.
1 j
string, string , .string ,.
1 j
char, char , .char ,.
1 j
function, function , .function ,.
1 j
c
8 � ISO/IEC 2007 – All rights reserved

class, class , .class ,.
1 j
symbol, symbol , .symbol ,.
1 j
x, x ,.x ,.
1 j
z, z , .z ,.
1 j
In this International Standard the conventions detailed below are used, except where noted:
-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.
create- 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- Within this International Standard, any functions named set-name are writers for a place,
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.
6 Lexemes
An ISLISP text is built up from lexemes. Lexemes are built up from at least the following
characters (see §20):
ABCDE FGHIJK LMNOPQ RSTUV WXYZ
abcde fghijk lmnopq rstuv wxyz
01234 56789+ -<>/*& =.?_! $%:@[] ^{}~#
Additional characters are implementation defined.
The following characters are individual lexemes (see §16 and §21.1):
(),’‘
The following character tuples (where n is a sequence of digits) are individual lexemes (see §12.7,
§16, and §22.1):
#’ #( ,@ #B #b #O #o #X #x #na#nA
The textual representations of symbols (see §18), numbers (see §19), characters (see §20), and
strings (see §24) are lexemes.
c
� ISO/IEC 2007 – All rights reserved 9

\ (single escape) and | (multiple escape) are special characters. They may occur in some
lexemes (identifiers and string literals).
Other lexemes are separated by delimiters. Delimiters are separators along with the following
characters:
()‘ ,’
The effect of delimiting is disestablished inside a string (see §24) or inside a corresponding pair
of multiple escape characters (see §18) or for the character immediately following #\.
6.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.
6.2 Comments
The character semicolon (;)isthe 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 #| and ending with |# is a comment. Such comments may
be nested.
Being a separator, a comment cannot occur inside a lexeme.
7 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 §6
Null The object nil is the only object whose class is . Upon input, it may be written as
nil or (). It is implementation defined whether nil prints as nil or ().
List Proper lists are those lists terminated by nil. Usually they are denoted as (obj obj
1 2
...obj ). A dotted list (i.e., a list whose last tail is not nil)appears as (obj obj
n 1 2
...obj . obj ).
n n+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.
Cons A cons is expressed as (car . cdr),wherethe car and cdr are objects.
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).
c
10 � ISO/IEC 2007 – All rights reserved

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
[s]dd.dE[s]dd.d
[s]dd.de[s]dd.d
where s is either “+”or “-”, and d is one of “0”–“9”. For example: 987.12, +12.5E-13,
-1.5E12, 1E32 .
Vector A vector of class is written as #(obj .obj ).
1 n
Array An array of class or can be written on input as #na
(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 (obj . obj ).If n>1andthe dimensions
1 n
are n n ., the structure is (str . str ),wherethe str are the structures of the
1 2 1 n i
n subarrays, each of which has dimensions (n .). As an example, the representation
1 2
of (create-array ’(2 3 4) 5) is as follows:
#3a(((5 5 5 5) (5555)(5555))((5555)(5555)(555 5))).
On output (see format), arrays of class will be printed using #(.)
notation.
String A string is represented by the sequence of its characters enclosed in a pair of "’s. For
example: "abc". Special characters are preceded with a backslash as an escape character.
Symbol A named symbol is represented by its print name. Vertical bars (|) might need to enclose
the symbol if it contains certain special characters; see §18. 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.
8 Reserved identifiers
Symbols whose names contain a colon (:)oranampersand(&) are reserved and may not be
used as identifiers. Symbols whose names start with colon (:) are called keywords.
9 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.
This number, although belonging to the set of natural numbers, usually is considered as only a floating point
number because of its representation.
c
� ISO/IEC 2007 – All rights reserved 11

9.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 form shall stop. If no active handler is established by
with-handler, 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.
9.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).
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. arity-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 §29.4.
c
12 � ISO/IEC 2007 – All rights reserved

10 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.
Aclass C is a direct superclass of a class C if C explicitly designates C as a superclass in
1 2 2 1
its definition, or if C is defined by this International Standard to be a direct superclass of C
1 2
(for example, by use of a directed arrow from C to C in Figure 1). In this case C is a direct
1 2 2
subclass of C .Aclass C is a superclass of a class C if there exists a series of classes
1 n 1
C ,.,C such that C is a direct superclass of C for 1≤i 2 n−1 i+1 i 1
subclass of C . A class is considered neither a superclass nor a subclass of itself. That is, if C
n 1
is a superclass of C ,then C�= C . The set of classes consisting of some given class C along
2 1 2
with all of its superclasses is called “C and its superclasses.”
If a user-defined class C inherits from two classes, C and C , the only superclasses that C and
1 2 1
C 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 C to C iff C is direct subclass of C . This graph is
1 2 2 1
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.
10.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 metaclass is used to refer to a
class that has instances that are themselves classes.
c
� ISO/IEC 2007 – All rights reserved 13


�

�

�

�

�

�

�

�

�

�

�

�

�

�
�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

Figure 1. Class Inheritance
c
14 � ISO/IEC 2007 – All rights reserved

The metaclass determines the form of inheritance used by the classes that are its instances and
the representation of the instances of those classes.
The ISLISP Object System provides the following predefined metaclasses:
• The class is the default class of classes defined by defclass.
• 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.
10.2 Predefined classes
The following classes are primitive classes in the class system (i.e., predefined classes that are
not metaclasses):













The classes and are predefined metaclasses.
A user-defined class, defined by defclass, 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 .
Figure 1 shows the required inheritance relationships among the classes defined by ISLISP.For
each pair of classes C and C in this figure, if C is linked directly by an arrow to C , C is a
1 2 1 2 1
direct superclass of C (and C is a direct subclass of C ). Additional relationships might exist,
2 2 1
subject to the following constraints:
1. It is implementation defined whether is a subclass of the
class .
2. 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
c
� ISO/IEC 2007 – All rights reserved 15

subclass relationships may exist between implementation-specific classes and classes
defined in this International Standard.
3. The class precedence list for observes the partial order , , ,
.
4. Users may define additional classes using defclass.
A built-in class is one whose instances have restricted capabilities or special representations. The
defclass defining form must not be used to
...