ISO/IEC 13816:2007
(Main)Information technology — Programming languages, their environments and system software interfaces — Programming language ISLISP
Information technology — Programming languages, their environments and system software interfaces — Programming language ISLISP
ISO/IEC 13816:2007 specifies syntax and semantics of the computer programming language ISLisp by specifying requirements for a conforming ISLisp processor and a conforming ISLisp text. The design goals for ISLisp are the following. ISLisp shall be compatible with existing Lisp dialects where feasible. ISLisp shall have as a primary goal to provide basic functionality. ISLisp shall be object-oriented. ISLisp shall be designed with extensibility in mind. ISLisp shall give priority to industrial needs over academic needs. ISLisp shall promote efficient implementations and applications. ISO/IEC 13816:2007 does not specify: 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; the minimal requirements of a data processing system that is capable of supporting an implementation of a processor for ISLisp; the method of preparation of an ISLisp text for execution and the method of activation of this ISLisp text, prepared for execution; the typographical presentation of an ISLisp text published for human reading; extensions that might or might not be provided by the implementation.
Technologies de l'information — Langages de programmation, leurs environnements et interfaces de logiciel système — Langage de programmation ISLISP
General Information
Relations
Standards Content (Sample)
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 13816:2007(E)
©
ISO/IEC 2007
---------------------- Page: 1 ----------------------
ISO/IEC 13816:2007(E)
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.
COPYRIGHT PROTECTED DOCUMENT
© 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
---------------------- Page: 2 ----------------------
ISO/IEC 13816:2007(E)
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
---------------------- Page: 3 ----------------------
ISO/IEC 13816:2007(E)
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
---------------------- Page: 4 ----------------------
ISO/IEC 13816:2007(E)
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
---------------------- Page: 5 ----------------------
ISO/IEC 13816:2007(E)
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
---------------------- Page: 6 ----------------------
ISO/IEC 13816:2007(E)
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
---------------------- Page: 7 ----------------------
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
---------------------- Page: 8 ----------------------
ISO/IEC 13816:2007(E)
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
---------------------- Page: 9 ----------------------
ISO/IEC 13816:2007(E)
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
---------------------- Page: 10 ----------------------
ISO/IEC 13816:2007(E)
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
---------------------- Page: 11 ----------------------
ISO/IEC 13816:2007(E)
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
---------------------- Page: 12 ----------------------
ISO/IEC 13816:2007(E)
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
---------------------- Page: 13 ----------------------
ISO/IEC 13816:2007(E)
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
---------------------- Page: 14 ----------------------
ISO/IEC 13816:2007(E)
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
---------------------- Page: 15 ----------------------
ISO/IEC 13816:2007(E)
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)
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.