ISO/IEC 13816:1997
(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
Technologies de l'information — Langages de programmation, leurs environnements et interfaces système — Langage de programmation ISLISP
General Information
Relations
Standards Content (Sample)
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)
---------------------- Page: 1 ----------------------
ISO/IEC 13816: 1997(E)
Contents
I Scope, Conventions and Compliance I
1
1.1 Scope .
1
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
10
1.9 Compliance of ISLISP Processors and Text .
2 Classes 10
11
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
17
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
24
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
---------------------- Page: 2 ----------------------
0 ISO/IEC ISO/IEC 13816:1997(E)
5 Predicates
26
5.1 Boolean Values 26
......................................
5.2 Class Predicates 26
.....................................
5.3 Equality 26
..........................................
5.4 Logical Connectives 29
...................................
6 Control Structure
30
30
6.1 Constants
.........................................
31
6.2 Variables
.........................................
6.3 Dynamic Variables 35
....................................
6.4 Conditional Expressions 36
.................................
6.5 Sequencing Forms 38
....................................
6.6 Iteration 39
..........................................
40
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
.....................................
48
7.1.1 Determining the Class Precedence List .
48
7.1.2 Accessing Slots .
49
7.1.3 Inheritance of Slots and Slot Options .
49
7.2 Generic Functions .
50
7.2.1 Defining Generic Functions .
51
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
56
7.3.4 Calling More General Methods .
57
7.4 Object Creation and Initialization .
58
7.4.1 Initialize-Object .
7.5 Class Enquiry 59
.......................................
60
8 Macros
61
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
.......................
65
10.1.3 niland 0 .
10.2 Symbol Properties 65
....................................
10.3 Unnamed Symbols 66
....................................
11 Number class 67
67
ll.lNumberclass. .
.-* 76
11.2 Float class. . .
78
11.3 Integer class .
..O
111
---------------------- Page: 3 ----------------------
0 ISOIIEC
ISO/IEC 13816:1997(E)
81
12 Character class
83
13 List class
83
13.1Cons . . . . . . . . . . . . . . . . . . . . . + . . . . . . . . . . . . . . . . . . . . .
85
13.2Nullclass . . . . . . . . . . . .-.-.=.-. . . . . . . . . . . . . . . . . . . . .
86
13.3 List operations . . . . . . . l . . l l . l . l l . . . . . . . . . . . . . . . . . . . . .
90
14 Arrays
90
14.1 Array Classes . . . . . . . . . . . . . . l . . . . . . . . . . . . . . . . . . . . . . . .
91
14.2 General Arrays . . . . . . . . . . . . . l . . . . . . . . . . . . . . . . . . . . . . . .
91
14.3 Array Operations . . . . . . . . . l l . l . . . . . . . . . . . . . . . . . . . . . . . .
94
15 Vectors
95
16 String class
98
17 Sequence Functions
101
18 Stream class
102
18.1 Streams to Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
104
18.2 Other Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
105
19 Input and Output
105
19.1 Argument Conventions for Input Functions . . . . . . . . . . . . . . . . . . . . . .
106
19.2 Character I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
110
19.3 Binary I/O .
111
20 Files
113
21 Condition System
113
21.1 Conditions. .
114
...........................
21.2 Signaling and Handling Conditions
114
..................
21.2.1 Operations relating to Condition Signaling
115
..................
21.2.2 Operations relating to Condition Handling
116
........................
21.3 Data associated with Condition Classes
116
21.3.1 Arithmetic Errors .
117
21.3.2 Domain Errors .
117
...................................
21.3.3 Parse Errors
117
...................................
21.3.4 Simple Errors
118
..................................
21.3.5 Stream Errors.
118
.............................
21.3.6 Undefined Entity Errors
118
21.4 Error Identification .
120
22 Miscellaneous
122
Index
iv
---------------------- Page: 4 ----------------------
0 ISOIIEC
ISO/IEC 13816:1997(E)
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.
---------------------- Page: 5 ----------------------
ISO/IEC 13816:1997(E)
@ 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
---------------------- Page: 6 ----------------------
ISO/IEC 13816:1997(EJ
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.
1
---------------------- Page: 7 ----------------------
ISO/IEC 13816:1997(E)
@ 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.
2
---------------------- Page: 8 ----------------------
@ ISO/IEC
ISO/IEC 13816:1997(E)
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:
---------------------- Page: 9 ----------------------
ISO/IEC 13816:1997(E)
@ 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 #\.
4
---------------------- Page: 10 ----------------------
@ ISO/IEC
ISO/IEC 13816:1997(E)
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
5
---------------------- Page: 11 ----------------------
ISO/IEC 13816:1997(E) @ ISO/IEC
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.
6
---------------------- Page: 12 ----------------------
@ 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.
---------------------- Page: 13 ----------------------
@ ISO/IEC
ISO/IEC 13816:1997(E)
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
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.