ISO/IEC 11404:1996

INTERNATIONAL
ISO/IEC
STANDARD
First edition
1996-l 2-l 5
Information technology - Programming
languages, their environments and system
software interfaces - Language-
independent datatypes
- Langages de programmation, leur
Technologies de /‘information
environnement et interfaces du logiciel systkme - Types de donnbes
indhpendan ts du langage
Reference number
ISO/lEC 11404:1996(E)
ISOAEC 11404:1996 (E)
Contents
V
.........................................................................................................
Foreword
vi
..................................................................................................
Introduction
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .“.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Scope
.........................................................................................
Conformance
.................................................................... L
2.1 Direct conformance
..................................................................
2.2 Indirect conformance
.........................................
2.3 Conformance of a mapping standard
..........................................................................
Normative References
Definitions .
.............................
Conventions Used in this International Standard
.............................................................................
Formal syntax
5.1
........................................................................
Text conventions
5.2
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fundamental Notions
Datatype .
6.1
Value space .
6.2
....................................................................
Datatype properties
6.3
.........................................................................
6.3.1 Equality
6.3.2 Order .
6.3.3 Bound .
....................................................................
6.3.4 Cardinality
.................................................
6.3.5 Exact and approximate
6.3.6 Numeric .
.......................................
Primitive and non-primitive datatypes
6.4
Datatype generator .
6.5
...........................................................
Characterizing operations
6.6
......................................................................
6.7 Datatype families
.................................................................
6.8 Aggregate datatypes
..............................................................
6.8.1 Homogeneity
0 ISO/IEC 1996
Unless otherwise specified, no part of this publication may be
All rights reserved.
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 0 Case Postale 56 0 CH- 1211 Geneve 20 0 Switzerland
Printed in Switzerland
lSO/lEC 11404:1996 (E)
0 ISOAEC
6.8.2 Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.8.3 Uniqueness
...................................
6.8.4 (Aggregate-imposed) ordering
...........................................................
6.8.5 Access method
....................................................
6.8.6 Recursive structure
.......................... 12
7 Elements of the Datatype Specification Language
.....................................................................
7.1 IDN character-set
...............................................................................
7.2 Whitespace
.........................................................................
7.3 Lexical objects
Identifiers .
7.3.1
Digit-string .
7.3.2
..............................
Character-literal and string-literal
7.3.3
Keywords .
7.3.4
Annotations .
7.4
Values .
7.5
....................................................
7.5.1 Independent values
.......................................................
7.5.2 Dependent values
............................................................................................
8 Datatypes
Primitive datatypes .
8.1
......................................................................
8.1.1 Boolean
8.1.2 State .
8.1.3 Enumerated .
8.1.4 Character .
Ordinal .
8.1.5
8.1.6 Date-and-Time .
8.1.7 Integer .
Rational .
8.1.8
Scaled .
8.1.9
8.1.10 Real .
.....................................................................
8.1.11 Complex
8.1.12 Void .
...................................................
8.2 Subtypes and extended types
Range .
8.2.1
8.2.2 Selecting .
Excluding .
8.2.3
Size .
8.2.4
Explicit subtypes .
8.2.5
Extended .
8.2.6
.................................................................
8.3 Generated datatypes
Choice .
8.3.1
Pointer .
8.3.2
...................................................................
8.3.3 Procedure
................................................................
8.4 Aggregate Datatypes
........................................................................
8.4.1 Record
8.4.2 Set .
8.4.3 .
Bag
....................................................................
8.4.4 Sequence
..........................................................................
8.4.5
AI-I-aY
...
III
ISOAEC 11404:1996 (E) 0 ISOAEC
8.4.6 Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5 Defined Datatypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9 Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
9.1 Type Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .~. 45
9.1.1 Renaming declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9.1.2 New datatype declarations . . . . . . . . . . . . . . . . . . . . . . . . .e.*.e 46
9.1.3 New generator declarations . . . . . . . . . . . . . . .o.o. 46
9.2 Value Declarations . . . . . . . . . . . . . . . . .~. 46
9.3 Termination Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
10 Defined Datatypes and Generators . 47
10.1 Defined datatypes . 47
10.1.1 Natural number . 47
10.1.2 Modulo . 48
10.1.3 Bit . 48
10.1.4 Bit string . 48
10.1.5 Character string . 49
10.1.6 Time interval
.............................................................. 50
10.1.7 Octet . 50
10.1.8 Octet string .
10.1.9 Private .
10.1.10 Object identifier
.......................................................... 51
10.2 Defined generators .
10.2.1 Stack .
10.2.2 Tree .
10.2.3 Cyclic enumerated .
10.2.4 Optional .
11 Mappings .
11.1 Outward Mappings .
11.2 Inward Mappings .
11.3 Reverse Inward Mapping .
11.4 Support of Datatypes
................................................................ 57
11.4.1 Support of equality
..................................................... 57
11.4.2 Support of order
.......................................................... 57
11.4.3 Support of bounds
.......................................................
11.4.4 Support of cardinality
................................................. 57
11.4.5 Support for the exact or approximate property
........... 58
11.4.6 Support for the numeric property
...............................
Annex A. Character-Set Standards
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Annex B. Recommended Placement of Annotations
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Annex C. Implementation Notions of Datatypes
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Annex D. Syntax for the Common Interface Definition Notation . . . . . . . . 67
Annex E. Example Mapping to Pascal
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Annex F. Example Mapping to MUMPS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Annex G. Resolved Issues
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ISO/lEC 11404:1996 (E)
0 ISOAEC
Foreword
IS0 (the international Organization for Standardization) and IEC (the In-
ternational 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 coommittees established by the respective organiza-
tion to deal with particular fields of technical activity. IS0 and IEC tech-
nical committees collaborate in fields of mutual interest. Other interna-
tional 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, ISO/IEC JTCI. Draft International Standards
adopted by the joint technical committee are circulated to national bod-
ies for voting. Publication as an International Standard requires approv-
al by at least 75% of the national bodies casting a vote.
International Standard ISO/IEC 11404 was prepared by Joint Technical
Committee ISO/IEC JTCl, Information technology, Subcommittee
SC22, Programming languages, their environments and system soft-
ware interfaces.
Annexes A to G of this International Standard are for information only.

0 ISOAEC
lSO/IEC 11404:1996 (E)
Introduction
Many specifications of software services and applications libraries are, or are in the process of becoming, Interna-
tional Standards. The interfaces to these libraries are often described by defining the form of reference, e.g. the “pro-
cedure call”, to each of the separate functions or services in the library, as it must appear in a user program written
Such an interface specification is com-
in some standard programming language (Fortran, COBOL, Pascal, etc.).
the “Fortran binding of PHIGS”
monly referred to as the “ binding of “, e.g.
Programmer’s Hierarchical Inter-
(ISO/IEC 9593-l : 1990, information processing systems - Computer Graphics -
active Graphics System (PHIGS) language bindings - Part I: FORTRAN).
This approach leads directly to a situation in which the standardization of a new service library immediately requires
the standardization of the interface bindings to every standard programming language whose users might reasonably
be expected to use the service, and the standardization of a new programming language immediately requires the
standardization of the interface binding to every standard service package which users of that language might rea-
sonably be expected to use. To avoid this n-to-m binding problem, ISO/IEC JTCl (Information Technology) assigned
to SC22 the task of developing an International Standard for Language-independent Procedure Calling and a parallel
International Standard for Language-Independent Datatypes, which could be used to describe the parameters to such
procedures.
This International Standard provides the specification for the Language-Independent Datatypes. It defines a set of
datatypes, independent of any particular programming language specification or implementation, that is rich enough
so that any common datatype in a standard programming language or service package can be mapped to some
datatype in the set.
The purpose of this International Standard is to facilitate commonality and interchange of datatype notions, at the con-
ceptual level, among different languages and language-related entities. Each datatype specified in this International
Standard has a certain basic set of properties sufficient to set it apart from the others and to facilitate identification of
the corresponding (or nearest corresponding) datatype to be found in other standards. Hence, this International Stan-
It is expected that
dard provides a single common reference model for all standards which use the concept datatype.
each programming language standard will define a mapping from the datatypes supported by that programming lan-
guage into the datatypes specified herein, semantically identifying its datatypes with datatypes of the reference mod-
el, and thereby with corresponding datatypes in other programming languages.
It is further expected that each programming language standard will define a mapping from those Language-lndepen-
dent (LI) Datatypes which that language can reasonably support into datatypes which may be specified in the pro-
gramming language. At the same time, this International Standard will be used, among other applications, to define
a “language-independent binding” of the parameters to the procedure calls constituting the principal elements of the
standard interface to each of the standard services. The production of such service bindings and language mappings
leads, in cooperation with the parallel Language-Independent Procedure Calling mechanism, to a situation in which
no further “ binding of ” documents need to be produced: Each service interface, by defining
its parameters using LI datatypes, effectively defines the binding of such parameters to any standard programming
language; and each language, by its mapping from the LI datatypes into the language datatypes, effectively defines
the binding to that language of parameters to any of the standard services.

INTERNATIONAL STANDARD 0 lSO/IEC ISO/IEC 11404: 1996 (E)
Information technology - Programming languages,
their environments and system software interfaces -
Language-independent datatypes
1 Scope
This International Standard specifies the nomenclature and shared semantics for a collection of datatypes commonly occurring
in programming languages and software interfaces, referred to as the Language-Independent (LI) Datatypes. It specifies both
primitive datatypes, in the sense of being defined ab initio without reference to other datatypes, and non-primitive datatypes, in
the sense of being wholly or partly defined in terms of other datatypes. The specification of datatypes in this International Stan-
dard is “language-independent” in the sense that the datatypes specified are classes of datatypes of which the actual datatypes
used in programming languages and other entities requiring the concept datatype are particular instances.
This International Standard expressly distinguishes three notions of “datatype”, namely:
l the conceptual, or abstract, notion of a datatype, which characterizes the datatype by its nominal values and properties;
l the structural notion of a datatype, which characterizes the datatype as a conceptual organization of specific component
datatypes with specific functionalities; and
l the implementation notion of a datatype, which characterizes the datatype by defining the rules for representation of the
datatype in a given environment.
This International Standard defines the abstract notions of many commonly used primitive and non-primitive datatypes which
possess the structural notion of atomicity. This International Standard does not define all atomic datatypes; it defines only those
which are common in programming languages and software interfaces. This International Standard defines structural notions for
the specification of other non-primitive datatypes and provides a means by which datatypes not defined herein can be defined
structurally in terms of the LI datatypes defined herein.
This International Standard defines a partial vocabulary for implementation notions of datatypes and provides for, but does not
require, the use of this vocabulary in the definition of datatypes. The primary purpose of this vocabulary is to identify common
implementation notions associated with datatypes and to distinguish them from conceptual notions. Specifications for the use of
implementation notions are deemed to be outside the scope of this International Standard, which is concerned solely with the
identification and distinction of datatypes.
This International Standard specifies the required elements of mappings between the LI datatypes and the datatypes of some other
language. This International Standard does not specify the precise form of a mapping, but rather the required information content
of a mapping.
2 Conformance
An information processing product, system, element or other entity may conform to this International Standard either directly,
by utilizing datatypes specified in this International Standard in a conforming manner (2.1), or indirectly, by means of mappings
between internal datatypes used by the entity and the datatypes specified in this International Standard (2.2).
NOTE - The general term information processing entity is used in this clause to include anything which processes information and contains
the concept of datatype. Information processing entities for which conformance to this International Standard may be appropriate include other
standards (e.g. standards for programming languages or language-related facilities), specifications, data handling facilities and services, etc.
0 ISOAEC
lSO/IEC 11404:1996 (E)
21 . Direct conformance
An information processing entity which conforms directly to this International Standard shall:
datatype generators specified in Clauses 8 and 10 are pro vided by the entity and
specify which of the datatypes and
which are not, and which, if any, of the declaration mechanisms in Clause 9 i t provides; and
ii) define the value spaces of the LI datatypes used by the entity to be identical to the value-spaces specified by this Inter-
national Standard; and
prescribed clauses 7 through 10 of this International Standard to refer to those datatypes and to no
iii) use the notation
bY
others; and
to the extent that the entity provides operations other than movement or translation of values, define operations on the
iv)
LI datatypes which can be derived from, or are otherwise consistent with, the characterizing operations specified by
this International Standard.
NOTES
1. This International Standard defines a syntax for the denotation of values of each datatype it defines, but, in general, requirement (iii) does
not require conformance to that syntax. Conformance to the value-syntax for a datatype is required only in those cases in which the value ap-
pears in a type-specifier, that is, only where the value is part of the identification of a datatype.
2. The requirements above prohibit the use of a type-specifier defined in this International Standard to designate any other datatype. They
make no other limitation on the definition of additional datatypes in a conforming entity, although it is recommended that either the form in
Clause 8 or the form in Clause 10 be used.
Requirement (iv) does not require all characterizing operations to be supported and permits additional operations to be provided. The
3.
intention is to permit addition of semantic interpretation to the LI datatypes and generators, as long as it does not conflict with the interpretations
given in this International Standard. A conflict arises only when a given characterizing operation could not be implemented or would not be
meaningful, given the entity-provided operations on the datatype.
Examples of entities which could conform directly are language definitions or interface specifications whose datatypes, and the notation
4.
for them, are those defined herein. In addition, the verbatim support by a software tool or application package of the datatype syntax and def-
inition facilities herein should not be precluded.
2.2 Indirect conformance
An information processing entity which conforms indirectly to this International Standard shall:
provide mappings between its in ternal d .ataty rpes and the LI datatypes con form ing to the specifications of Clause 11 of
this International Standard; and
ii) specify for which of the datatypes in Clause 8 and Clause 10 an inward mapping is provided, for which an outward
mapping is provided, and for which no mapping is provided.
NOTES
Standards for existing programming languages are expected to provide for indirect conformance rather than direct conformance.
1.
Examples of entities which could conform indirectly are language definitions and implementations, information exchange specifications
2.
and tools, software engineering tools and interface specifications, and many other entities which have a concept of datatype and an existing
notation for it.
2.3 Conformance of a mapping standard
In order to conform to this International Standard, a standard mapping shall include
for a in its conformance requirements the
requirement to conform to this International Standard.
NOTES
envisaged that this International Standard w
1. It is ill be accompanied by other standards specifying mappings between the
internal datatypes
in language and language-related standards
specified and the LI datatypes. Such mapping standards are required to comply
with this Intema-
lSO/lEC 11404:1996 (E)
o ISOAEC
tional Standard.
2. Such mapping standards may define “generic” mappings, in the sense that for a given internal datatype the standard specifies a parame-
trized LI datatype in which the parametric values are not derived from parametric values of the internal datatype nor specified by the standard
itself, but rather are required to be specified by a “user” or “implementor” of the mapping standard. That is, instead of specifying a particular
LI datatype, the mapping specifies a family of LI datatypes and requires a further user or implementor to specify which member of the family
applies to a particular use of the mapping standard. This is always necessary when the internal datatypes themselves are, in the intention of the
language standard, either explicitly or implicitly parametrized. For example, a programming language standard may define a datatype INTE-
GER with the provision that a conforming processor will implement some range of Integer; hence the mapping standard may map the internal
datatype INTEGER to the LI datatype :
integer range (min.max),
and require a conforming processor to provide values for “mint’ and “max”.
3 Normative References
The following standards contain provisions which, through reference in this text, constitute provisions of this International Stan-
dard. 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 stan-
dards indicated below. Members of IEC and IS0 maintain registers of current valid International Standards.
ISO/IEC 8601: 1988, Data elements and interchange formats - Information interchange -Representation of dates and times.
Open Systems Interconnection - Specification of Abstract Syntax Notation One
ISO/IEC 8824: 1990, Information technology -
(ASN.1).
ISO/IEC 10646- 1: 1993, Information technology - Universal Multiple-Octet Coded Character Set (UC‘S) -
Part 1: Architecture and Basic Multilingual Plane.
4 Definitions
For the purposes of this International Standard, the following definitions apply.
NOTE - These definitions may not coincide with accepted mathematical or programming language definitions of the same terms.
4.1 actual parametric datatype :a datatype appearing as a parametric datatype in a use of a datatype generator, as opposed
ZiI-1 ng in the definition of the datatype generator.
to the formal-parametric-types appe
4.2 actual parametric value: a value appearing as a parametric value in a reference to a datatype family or datatype generator,
as opposed to the formaLparametric-values appearing in the corresponding definition S.
4.3 aggregate datatype: a generated datatype each of whose values is made up of values of the component datatypes, in the
that operations on all component v alues are meaningful.
sense
4.4 annotation: a descriptive information unit attached to a datatype, or a component of a datatype, or a procedure (value),
to characterize some aspect of the representations, variables, or operations associated with values of the datatype which goes be-
yond the scope of this International Standard.
, approximate: a property of a datatype indicating that there is not a 1 -to- 1 relationship V ,alues
4.5 between of the conceptual
of a valid computational model of the datatype.
datatype and the values
4.6 bounded: a property of a datatype, meaning both bounded above and bounded below.
bounded above:
4.7 a of a datatype indicating that there is a value U in the value space such that, for all values s in
property
the value space, s < U.
4.8 bounded below: a ofa datatype indicating that there is a value L in the value space such that, for all values s in
property
the value space, L < s.
4.9 characterizing operations:
(of a datatype): a collection of operations on, or yielding, values of the datatype, which distinguish this datatype from
0 ISOAEC
ISOAEC 11404:1996 (E)
other datatypes with identical value spaces;
a collection of operations on, or yielding, values of any datatype resulting from an application
(of a datatype generator):
of the datatype generator, which distinguish this datatype generator from other datatype generators which produce identical value
spaces from identical parametric datatypes.
4.10 component datatype: a datatype which is a parametric datatype to a datatype generator, i.e. a datatype on which the
datatype generator operates.
datatype: a set of distinct values, characterized by properties of those values and by operations on those values.
4.11
4.12 datatype declaration:
(1) the means provided by this International Standard for the definition of a LI datatype which is not itself defined by this
International Standard;
(2) an instance of use of this means.
4.13 datatype family: a collection of datatypes which have equivalent characterizing operations and relationships, but value
spaces which differ in the number and identification of the individual values.
datatype generator: an operation on datatypes, as objects distinct from their values, which generates new datatypes.
4.14
4.15 defined datatype: a datatype defined by a type-declaration.
4.16 defined generator: a datatype generator defined by a type-declaration.
conceptual d .atatype is distinct from all others in any valid
4.17 exact: a property of a datatype indicating that every value of the
compu tational model of the datatype.
an identifier, appearing in the definition of a datatype generator, for which a LI datatype will
4.18 formal-parametric-type:
from the generator.
be substituted in any reference to a (defined) datatype resulting
4.19 formal-parametric-value: an identi fier, appearing in the definition of a datatype family or datatype generator, for which
a value will be substituted in any reference to a (defined) datatype in the family or resulting from the generator.
previously-defined
4.20 generated datatype: a datatype defined by the application of a datatype generator to one or more
datatypes.
4.21 generated internal datatype: a datatype defined by the application of a datatype generator defined in a particular pro-
gramming language to one or more previously-defined internal datatypes.
4.22 generator: a datatype generator (q.v.).
4.23 generator declaration:
(1) the means provided by this International Standard for the definition of a datatype generator which is not itself defined
by this International Standard;
(2) an instance of use of this means.
internal datatype: a datatype whose
4.24 syntax and semantics are defined by some other standard, language, product, service
or other information processing entity.
inward mapping: a conceptual association between the internal
4.25 datatypes ofal anguage and the LI datatypes which as-
to each LI datatype either a single semantically equivalent internal
signs datatype or no equivalent intern al datatype.
4.26 LI datatype:
(1) a datatype defined by this International Standard, or
(2) a datatype defined by the means of datatype definition provided by this International Standard.
4.27 lower bound: in a datatype which is bounded below, the value L such that, for all values s in the value space, L < s.
4.28 mapping:
(of datatypes): a formal specification of the relationship between the (internal) datatypes which are notions of, and spec-
ifiable in, a particular programming language and the (LI) datatypes specified in this International Standard;
lSO/lEC 11404:1996 (E)
0 ISOAEC
(of values): a corresponding specification of the relationships between values of the internal datatypes and values of the
LI datatypes.
4.29 order: a mathematical relationship among values (see 6.3.2).
4.30 ordered: a property of a datatype which is determined by the existence and specification of an order relationship on its
value space.
4.31 outward mapping: a conceptual association between the internal datatypes of a language and the LI datatypes which
identifies each internal datatype with a single semantically equivalent LI datatype.
r
4.32 parametric datatype: a datatype on which a datatype generator operates to produce a generated-datatype.
4.33 parametric value:
(1) a value which distinguishes one member of a datatype family from another, or
(2) a value which is a parameter of a datatype or datatype generator defined by a type-declaration (see 9.1).
4.34 primitive datatype: an identifiable datatype that cannot be decomposed into other identifiable datatypes without loss of
all semantics associated with the datatype.
4.35 primitive internal datatype: a datatype in a particular programming language whose values are not viewed as being con-
structed in any way from values of other datatypes in the language.
4.36 representation:
(of a LI datatype): the mapping from the value space of the LI datatype to the value space of some internal datatype of a
computer system, file system or communications environment;
(of a value): the image of that value in the representation of the datatype.
4.37 subtype: a datatype derived from another datatype by restricting the value space to a subset whilst maintaining all char-
acterizing operations.
4.38 upper bound: in a datatype which is bounded above, the value U such that, for all values s in the value space, s < U.
4.39 value space: the set of values for a given datatype.
4.40 variable: a computational object to which a value of a particular datatype is associated at any given time; and to which
different values of the same datatype may be associated at different times.
5 Conventions Used in this International Standard
5.1 Formal syntax
I
This International Standard defines a formal datatype specification language. The following notation, derived from Backus-Naur
form, is used in defining that language. In this clause, the word mark is used to refer to the characters used to define the syntax,
while the word character is used to refer to the characters used in the actual datatype specification language. Table 5-l summa-
rizes the syntactic metanotation.
Table 5-I - Metanotation Marks
I
(QUOTATION MARK) delimits a terminal symbol
(APOSTROPHE)
delimits a terminal symbol
(CURLY SRACKETS) delimit a repeated sequence (zero or more occurrences)
(SQUARE BRACKETS delimit an optional sequence (zero or one occurrence)
)
(VERTICAL LINE) delimits an alternative sequence
(EQUALS SIGN) separates a non-terminal symbol from its definition
. (FULL STOP) terminates a production
0 ISOAEC
ISOAEC 11404:1996 (E)
A terminal symbol is a sequence of marks beginning with either a QUOTATION MARK (“) or an APOSTROPHE mark (‘)
and terminated by the next occurrence of the same mark. The terminal symbol represents the occurrence of the sequence of char-
acters in an implementation character-set corresponding to the marks enclosed by (but not including) the QUOTATION MARK
or APOSTROPHE delimiters
A non-terminal symbol is a sequence of marks, each of which is either a letter or the HYPHEN-MINUS (-) mark, terminated
by the first mark which is neither a letter nor a HYPHEN-MINUS. A non-terminal symbol represents any sequence of terminal
symbols which satisfies the production for that non-terminal symbol. For each non-terminal symbol there is exactly one produc-
tion in clauses 7, 8,9, and 10.
S represented by each symbol in the
A sequence of symbols represents exactly one occurrence of a (group of) terminal symbol
symbols appear in the sequence, and no other symbols.
sequence in the order in which the
A repeated sequence is a sequence of terminal and/or non-terminal symbols enclosed between a LEFT CURLY BRACKET
mark (0 and a RIGHT CURLY BRACKET mark 0). A repeated sequence represents any number of consecutive occurrences
of the sequence of symbols so enclosed, including no occurrence.
An optional sequence is a sequence of terminal and/or non-terminal symbols enclosed between a LEFT SQUARE BRACKET
mark ([) and a RIGHT SQUARE BRACKET mark (I). An optional sequence represents either exactly one occurrence of the
sequence of symbols so enclosed or no symbols at all.
An alternative sequence is a sequence of terminal and/or non-terminal symbols preceded by a VERTICAL LINE (I) mark and
followed by either a VERTICAL LINE mark or a FULL STOP mark (.). An alternative sequence represents the occurrence of
either the sequence of symbols so delimited or the sequence of symbols preceding the (first) VERTICAL LINE mark.
A production defines the valid sequences of symbols which a non-terminal symbol represents. A production has the form:
non-terminal-symbol = valid-sequence .
where valid-sequence is any sequence of terminal symbols, non-terminal symbols, optional sequences, repeated sequences and
alternative sequences. The EQUALS SIGN (=) mark separates the non-terminal symbol being defined from the valid-sequence
which represents its definition. The FULL STOP mark terminates the valid-sequence.
5.2 Text conventions
Within the text:
l A reference to a terminal symbol syntactic object consists of the terminal symbol in quotation marks, e.g. “type”.
l A reference to a non-terminal symbol syntactic object consists of the non-terminal-symbol in italic script, e.g. type-dec-
laration.
l Non-italicized words which are identical or nearly identical in spelling to a non-terminal-symbol refer to the conceptual
object represented by the syntactic object. In particular, xxx-type refers to the syntactic representation of an “xxx datatype”
in all occurrences.
6 Fundamental Notions
6.1 Datatype
A datatype is a a set of distinct values, characterized by properties of those values and by operations on those values. Charac-
terizing operations are included in this International Standard solely in order to identify the datatype. In this International Stan-
dard, characterizing operations are purely informative and have no normative impact.
NOTE! - Characterizing operations are
included in order to assist in the identification of the appropriate
datatypes for particular purposes, such
as mapping to programming languages.
The term LI datatype (for Language-Independent datatype) is used to mean a datatype defined by this International Standard.
LI datatypes (plural) refers to some or all of the datatypes defined by this International Standard.
The term internal datatype is used to mean a datatype whose syntax and semantics are defined by some other standard, language,
product, service or other information processing entity.
lSO/lEC 11404:1996 (E)
0 lSO/IEC
not in the sense that they are directly supported by, i.e. “built-in” to, many
NOTE - The datatypes included in this standard are “common”,
languages, but in the sense that they are common and useful generic concepts among users of datatypes, which include, but go well beyond,
programming languages.
6.2 Value space
A value space is the collection of values for a given datatype. The value space of a given datatype can be defined in one of the
following ways:
l enumerated outright, or
* defined axiomatically from fundamental notions, or
a defined as the subset of those values from some already defined value space which have a given set of properties, or
l defined as a combination of arbitrary values from some already defined value spaces by a specified construction proce-
dure.
Every distinct value belongs to exactly one datatype, although it may belong to many subtypes of that datatype (see 8.2).
6.3 Datatype properties
The model of datatypes used in this International Standard is said to be an “abstract computational model”. It is “computational”
in the sense that it deals with the manipulation of information by computer systems and makes distinctions in the typing of infor-
mation units which are appropriate to that kind of manipulation. It is “abstract” in the sense that it deals with the perceived prop-
erties of the information units themselves, rather than with the properties of their representations in computer systems.
NOTES
1. It is important to differentiate between the values, relationships and operations for a datatype and the representations of those values, re-
lationships and operations in computer systems. This International Standard specifies the characteristics of the conceptual datatypes, but it only
provides a means for specification of characteristics of representations of the datatypes.
2. Some computational properties derive from the need for the information units to be representable in computers. Such properties are
deemed to be appropriate to the abstract computational model, as opposed to purely representational properties, which derive from the nature
of specijk representations of the information units.
3. It is not proper to describe the datatype model used herein as “mathematical”, because a truly mathematical model has no notions of “ac-
cess to information units” or “invocation of processing elements”, and these notions are important to the definition of characterizing operations
for datatypes and datatype generators.
Equality
6.3.1
In every value space there is a notion of equality, for which the following rules hold:
l for any two instances (a, b) of values from the value space, either a is equal to b, denoted a = b, or a is not equal to b,
denoted a # b;
l there is no pair of instances (a, b) of values from the value space such that both a = b and a # b;
l for every value a from the value space, a = a;
0 for any two instances (a, b) of values from the value space, a = b if and only if b = a;
l for any three instances (a, b, c) of values from the value space, if a = b and b = c, then a = c.
every datatype, the operation Equal is defined in terms of the equality property of the value space, by:
On
l for any values a, b drawn from the value space, Equal(a,b) is true if a = b, andfalse otherwise.
6.3.2 Order
A value space is said to be ordered if there exists for the value space an order relation, denoted I, with the following rules:
l for every pair of values (a, b) from the value space, either a 5 b or b 5
...