ISO/IEC TR 10176:2001

TECHNICAL ISO/IEC
REPORT TR
10176
Third edition
2001-07-01
Information technology — Guidelines for
the preparation of programming language
standards
Technologies de l'information — Lignes directrices pour la préparation des
normes des langages de programmation
Reference number
ISO/IEC TR 10176:2001(E)
©
ISO/IEC 2001

---------------------- Page: 1 ----------------------
ISO/IEC TR 10176:2001(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.
© ISO/IEC 2001
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.ch
Web www.iso.ch
Printed in Switzerland
ii © ISO/IEC 2001 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/IEC TR 10176:2001(E)
Contents Page
1 Scope .1
2 References.1
3 Terms and definitions .1
4 Guidelines.6
4.1 Guidelines for the form and content of standards.6
4.1.1 Guideline: The general framework.6
4.1.2 Guideline: Definitions of syntax and semantics.7
4.1.3 Guidelines on the use of character sets .8
4.1.4 Guideline: Error detection requirements .13
4.1.5 Guideline: Exception detection requirements.16
4.1.6 Guideline: Static detection of exceptions .18
4.1.7 Guideline: Recovery from non-fatal errors and exceptions.19
4.1.8 Guideline: Requirements on user documentation .19
4.1.9 Guideline: Provision of processor options.19
4.1.10 Guideline: Processor-defined limits .21
4.2 Guidelines on presentation .22
4.2.1 Guideline: Terminology.22
4.2.2 Guideline: Presentation of source programs .23
4.3 Guidelines on processor dependence .23
4.3.1 Guideline: Completeness of definition.23
4.3.2 Guideline: Optional language features.23
4.3.3 Guideline: Management of optional language features.23
4.3.4 Guideline: Syntax and semantics of optional language features.24
4.3.5 Guideline: Predefined keywords and identifiers .24
4.3.6 Guideline: Definition of optional features .24
4.3.7 Guideline: Processor dependence in numerical processing.25
4.4 Guidelines on conformity requirements .25
4.5 Guidelines on strategy .25
4.5.1 Guideline: Secondary standards.25
4.5.2 Guideline: Incremental standards.25
4.5.3 Guideline: Consistency of use of guidelines.26
4.5.4 Guideline: Revision compatibility.26
4.6 Guidelines on cross-language issues .28
4.6.1 Guideline: Binding to functional standards.28
4.6.2 Guideline: Facilitation of binding.28
4.6.3 Guideline: Conformity with multi-level functional standards .29
4.6.4 Guideline: Mixed language programming.29
4.6.5 Guideline: Common elements.29
4.6.6 Guideline: Use of data dictionaries.29
4.7 Guidelines on Internationalization.29
4.7.1 Guideline: Cultural convention set switching mechanism .29
4.7.2 Guideline: Cultural convention related functionality.30
Annex A Recommended extended repertoire for user-defined identifiers.31
© ISO/IEC 2001 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO/IEC TR 10176:2001(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.
The main task of technical committees is to prepare International Standards, but in exceptional circumstances a
technical committee may propose the publication of a Technical Report of one of the following types:
— type 1, when the required support cannot be obtained for the publication of an International Standard, despite
repeated efforts;
— type 2, when the subject is still under technical development or where for any other reason there is the future
but not immediate possibility of an agreement on an International Standard;
— type 3, when a technical committee has collected data of a different kind from that which is normally published
as an International Standard (“state of the art”, for example).
Technical Reports of types 1 and 2 are subject to review within three years of publication, to decide whether they
can be transformed into International Standards. Technical Reports of type 3 do not necessarily have to be
reviewed until the data they provide are considered to be no longer valid or useful.
Technical Reports are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.
Attention is drawn to the possibility that some of the elements of this Technical Report 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 TR 10176, which is a Technical Report of type 3, was prepared by Joint Technical Committee
ISO/IEC JTC 1, Information technology, Subcommittee SC 22, Programming languages, their environments and
system software interfaces.
This third edition cancels and replaces the second edition (ISO/IEC TR 10176:1998), which has been technically
revised.
iv © ISO/IEC 2001 – All rights reserved

---------------------- Page: 4 ----------------------
ISO/IEC TR 10176:2001(E)
Introduction
Background: Over the last decades (since 1966), standards have been produced for a number of computer
programming languages. Each has dealt with its own language in isolation, although to some extent the drafting
committees have become more expert by learning from both the successes and the mistakes of their predecessors.
The first edition of this Technical Report was produced during the 1980s to put together some of the experience
that had been gained to that time, in a set of guidelines, designed to ease the task of drafting committees of
programming language standards. Subsequent editions enhance the guidelines to take into account experiences
and developments in the area of internationalization and character sets, especially with the expanding repertoire of
ISO/IEC 10646.
This document is published as a Technical Report type 3 because the design of programming languages - and
hence requirements relating to their standardization - is still evolving fairly rapidly, and because existing languages,
both standardized and unstandardized, vary so greatly in their properties and styles that publication as a full
standard, even as a standard set of guidelines, did not seem appropriate at this time.
The need for guidelines: While each language, taken as a whole, is unique, there are many individual features
that are common to many, or even to most of them. While standardization should not inhibit such diversity as is
essential, both in the languages and in the form of their standards, unnecessary diversity is better avoided.
Unnecessary diversity leads to unnecessary confusion, unnecessary retraining, unnecessary conversion or
redevelopment, and unnecessary costs. The aim of the guidelines is therefore to help to achieve standardization
across languages and across their standards.
The existence of a guideline will often save a drafting committee from much discussion of detailed points all of
which have been discussed previously for other languages.
Furthermore the avoidance of needless diversity between languages makes it easier for programmers to switch
between one and another.
NOTE Diversity is a major problem because it uses up time and resources better devoted to the essential part, both by
makers and users of standards. Building a language standard is very expensive in resources and far too much time and effort
goes into “reinventing the wheel” and trying to solve again, from the beginning, the same problems that other committees have
faced.
However, a software writer faced with the task of building (say) a support environment (operating system facilities, utilities, etc.)
for a number of different language processors is also faced with many problems from the eventual standards. Quite apart from
the essential differences between the languages, there are to begin with the variations of layout, arrangement, terminology,
metalanguages, etc. Much worse, there are the variations between requirements of basically the same kind, some substantial,
some slight, some subtle - compounded by needless variations in the way they are specified. This represents an immense extra
burden - as does the duplication in providing different support tools for different languages performing basically the same task.
How to use this Technical Report: This Technical Report does not seek to legislate on how programming
languages should be designed or standardized: it would be futile even to attempt that. The guidelines are, as their
name implies, intended for guidance only. Nevertheless, drafting committees are strongly urged to examine them
seriously, to consider each one with care, and to adopt its recommendation where practicable. The guidelines have
been so written that it will be possible in most cases to determine, by examination, whether a given programming
language standard has been produced in accordance with a given guideline, or otherwise. However, the
conclusions to be drawn from such an assessment, and consequent action to be taken, are matters for individual
users of this Technical Report and are beyond its scope.
Reasons for not adopting any particular guideline should be documented and made available, (e.g. in an
informative annex of the programming language standard). This and the reason therefore can be taken into
account at future revisions of the programming language standard or this technical report.
© ISO/IEC 2001 – All rights reserved v

---------------------- Page: 5 ----------------------
ISO/IEC TR 10176:2001(E)
Of course, care must naturally be taken when following these guidelines to do so in a way which does not conflict
with the ISO/IEC Directives, or other rules of the standards body under whose direction the standard is being
prepared.
Further related guidelines: This Technical Report is concerned with the generality of programming languages and
general issues concerning questions of standardization of programming languages, and is not claimed to be
necessarily universally applicable to all languages in all circumstances. Particular languages or kinds of languages,
or particular areas of concern, may need more detailed and more specific guidelines than would be appropriate for
this Technical Report. At the time of publication, some specific areas are already the subject of more detailed
guidelines, to be found in existing or forthcoming Technical Reports. Such Technical Reports may extend, interpret,
or adapt the guidelines in this Technical Report to cover specific issues and areas of application. Users of this
Technical Report are recommended to take such other guidelines into account, as well as those in this Technical
Report, where the circumstances are appropriate. See, in particular, ISO/TR 9547 and ISO/IEC TR 10034.
vi © ISO/IEC 2001 – All rights reserved

---------------------- Page: 6 ----------------------
TECHNICAL REPORT ISO/IEC TR 10176:2001(E)
Information technology – Guidelines for the preparation of
programming language standards
1 Scope
This Technical Report presents a set of guidelines for producing a standard for a programming language.
2 References
ISO/IEC 646:1991, Information technology — ISO 7-bit coded character set for information interchange.
ISO/IEC 2022:1994, Information technology — Character code structure and extension techniques.
ISO 2382-15:1999, Information technology — Vocabulary — Part 15: Programming languages.
ISO/IEC 4873:1991, Information technology — ISO 8-bit code for information interchange — Structure and rules for
implementation.
ISO/IEC 6937:1994, Information technology — Coded graphic character set for text communication — Latin
alphabet.
ISO/IEC 8859-1:1998, Information technology — 8-bit single-byte coded graphic character sets — Part 1: Latin
alphabet No. 1.
ISO/TR 9547:1988, Programming language processors — Test methods — Guidelines for their development and
acceptability.
ISO/IEC TR 10034:1990, Guidelines for the preparation of conformity clauses in programming language standards.
ISO/IEC 10646-1:2000, Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 1:
Architecture and Basic Multilingual Plane.
ISO/IEC TR 11017:1998, Information technology — Framework for internationalization.
ISO/IEC 11404:1996, Information technology — Programming languages, their environments and system software
interfaces — Language-independent datatypes.
ISO/IEC 14977:1996, Information technology — Syntactic metalanguages — Extended BNF.
3 Terms and definitions
For the purposes of this Technical Report, the following terms and definitions apply.
It is not claimed that all language standards necessarily use the terminology in the senses defined here; where
appropriate, the necessary interpretations and conversions would need to be carried out when applying these
guidelines in a particular case. Also, not all language standards use the terminology of ISO 2382-15; the
terminology defined here, itself divergent in some cases from that in ISO 2382-15, has been introduced to minimize
confusion which might result from such difference. Some remarks are made below about particular divergences
from ISO 2382-15, for further clarification.
© ISO/IEC 2001 – All rights reserved 1

---------------------- Page: 7 ----------------------
ISO/IEC TR 10176:2001(E)
3.1 programming language processor (abbreviated where there is no ambiguity to processor)
Denotes the entire computing system which enables the programming language user to translate and execute
programs written in the language, in general consisting both of hardware and of the relevant associated software.
NOTE 1 A “processor” in the sense of this Technical Report therefore consists of more than simply (say) a “compiler” or an
“implementation” in conventional terminology; in general it consists of a package of facilities, of which a “compiler” in the
conventional sense may be only one. There is also no implication that the processor consists of a monolithic entity, however
constituted. For example, processor software may consist of a syntax checker, a code generator, a link-loader, and a run-time
support package, each of which exists as a logically distinct entity. The “processor” in this case would be the assemblage of all
of these and the associated hardware. Conformity to the standard would apply to the assemblage as a whole, not to individual
parts of it.
NOTE 2 In ISO/TR 9547 the term “processor” is used in a more restricted sense. For the purposes of ISO/TR 9547, a
differentiation is necessary between “processor” and “configuration”; that distinction is not necessary in this Technical Report.
Those using both Technical Reports will need to bear this difference in terminology in mind. See 3.3.4 for another instance of a
difference in terminology, where a distinction which is not necessary in ISO/TR 9547 has to be made in this Technical Report.
3.2 syntax and semantics
Denote the grammatical rules of the language. The term syntax refers to the rules that determine whether a
program text is well-formed. The syntactic rules need not be exclusively “context-free”, but must allow a processor
to decide, solely by inspection of a program text, with a practicable amount of effort and within a practicable amount
of time, whether that text conforms to the rules. An error (see 3.3.1) is a violation of the syntactic rules.
The term semantics refers to the rules which determine the behaviour of processors when executing well-formed
programs. An exception (see 3.3.2) is a violation of a non-syntactic requirement on programs.
NOTE In ISO 2382-15 the term static is defined (15.02.09) as “pertaining to properties that can be established before the
execution of a program” and dynamic (15.02.10) as “pertaining to properties that can only be established during the execution
of a program”. These therefore appear to be close to the terms “syntax” and “semantics” respectively as defined in this
Technical Report. ISO 2382-15 does not define “syntax” or “semantics”, though these are terms very commonly used in the
programming language community.
Furthermore, the uses of “static” and “dynamic” (and other terms) in ISO 2382-15 seem designed for use within a single
language rather than across all languages, but while that terminology can mostly be applied consistently within a single
language, it becomes much harder to do so across the generality of languages, which is the need in this Technical Report. This
problem is not totally absent with “syntax/semantics” but is much less acute.
3.3 Errors, Exceptions, Conditions
3.3.1 errors
The incorrect program constructs which are statically determinable solely from inspection of the program text,
without execution, and from knowledge of the language syntax. A fatal error is one from which recovery is not
possible, i.e. it is not possible to proceed to (or continue with) program execution. A non-fatal error is one from
which such recovery is possible.
NOTE A fatal error may not necessarily preclude the processor from continuing to process the program, in ways which do
not involve program execution (for example, further static analysis of the program text).
3.3.2 exceptions
The instances of incorrect program functioning which in general are determinable only dynamically, through
execution of the program. A fatal exception is one from which recovery is not possible, i.e. it is not possible to
continue with (or to proceed to) program execution. A non-fatal exception is one from which recovery is possible.
NOTE 1 In case of doubt, “possible” within this section should be interpreted as “possible without violating definitions within
or requirements of the standard”. For example, the hardware element of a language processor may have the technical capability
of continuing program execution after division by zero, but in terms of a language standard which defines division by zero as a
fatal exception, the consequences of such continued execution would not be meaningful.
NOTE 2 See also 3.3.4.
2 © ISO/IEC 2001 – All rights reserved

---------------------- Page: 8 ----------------------
ISO/IEC TR 10176:2001(E)
3.3.3 conditions
Occurrences during execution of the program which cause an interruption of normal processing when detected. A
condition may be an exception, or may be some language-defined or user-defined occurrence, depending on the
language.
NOTE For example, reaching end-of-file on input may always be an exception in one language, may always be a condition
in another, while in a third it may be a condition if action to be taken on detection is specified in the program, but an exception if
its occurrence is not anticipated.
3.3.4 Relationship to other terminology
In ISO/TR 9547 the term “error” is used in a more general sense to encompass what this Technical Report terms
“exceptions” as well as “errors”. For the purposes of ISO/TR 9547, the differentiation made here is not necessary.
Those using both Technical Reports will need to bear this difference in terminology in mind. See note 2 of 3.1 for
another instance of a difference in terminology, where a distinction has to be made in ISO/TR 9547 which is not
necessary in this Technical Report.
ISO 2382-15 does not define “error” but does define “exception (in a programming language)” (15.06.12). The
definition reads “A special situation which may arise during execution, which is considered abnormal, which may
cause a deviation from the normal execution sequence, and for which facilities exist in the programming language
to define, raise, recognize, ignore and handle it”. ON-conditions in PL/I and exceptions in Ada are cited as
examples.
The reason for not using this terminology in this Technical Report, which deals with the generality of existing and
potential standardized languages rather than just a single one, is that it makes it difficult to distinguish (as this
Technical Report needs to do) between “pure” exceptions, more general conditions, and processor options for
exception handling which are built into the language (all in the senses defined in this Technical Report). It also
does not aid making sufficient distinction between ON-conditions being enabled or disabled (globally or locally), nor
whether the condition handler is the system default or provided by the programmer.
3.4 Processor dependence
For the purposes of this Technical Report, the following definitions are assumed.
If this Technical Report refers to a feature being left undefined in a standard (though referred to within the
standard), this means that no requirement is specified concerning its provision and the effect of attempting to use
the feature cannot be predicted.
If this Technical Report refers to a feature being processor-dependent, this means that the standard requires the
processor to supply the feature but that there are no further requirements upon how it is provided.
If this Technical Report refers to a feature being processor-defined, this means that its definition is left processor-
dependent by the standard, but that the definition shall be explicitly specified and made available to the user in
some appropriate form (such as part of the documentation accompanying the processor, or through use of an
environmental enquiry function).
NOTE 1 The term “feature” is used here to encompass both language features (syntactic elements a change to which would
change the text of a program) and processor features (e.g. processor options, or accompanying documentation, a change to
which would not change the text of a program). Examples of features which are commonly left undefined, processor-dependent
or processor-defined are the collating sequence of the supported character set (a language feature) and processor action on
detection of an exception (a processor feature).
NOTE 2 In any particular instance the precise effect of the use of any of these terms may be affected by the nature of the
feature concerned and the context in which the term is used.
NOTE 3 None of the above terms specifically covers the case where reference to a feature is omitted altogether from the
standard. While in general this might be regarded as “implicit undefined”, it is possible that an unmentioned feature might
necessarily have to be supplied for the processor to be usable (and would hence be processor-dependent) and that some
aspects of the feature might in turn have to be processor-defined for the feature to be usable.
© ISO/IEC 2001 – All rights reserved 3

---------------------- Page: 9 ----------------------
ISO/IEC TR 10176:2001(E)
3.5 Secondary, Incremental and supplementary standards
3.5.1 Secondary standards
In this Technical Report, a secondary standard is one which requires strict conformity with another (“primary”)
standard - or possibly more than one primary standard - but places further requirements on conforming products
(e.g. in the context of this Technical Report, on language processors or programs).
NOTE A possible secondary standard for conforming programs might specify additional requirements with respect to use of
comments and indentation, provision of documentation, use of conventions for naming user-defined identifiers, etc.
A possible secondary standard for conforming processors might specify additional requirements with respect to error and
exception handling, range and accuracy of arithmetic, complexity of programs which can be processed, etc.
3.5.2 Incremental standards
In this Technical Report, an incremental standard adds to an existing standard without modifying its content. Its
purpose is to supplement the coverage of the existing standard within its scope (e.g. language definition) rather
than (as with a secondary standard, see 3.5.1) to add further requirements upon products conforming with an
existing standard which are outside that scope. It is recognized that in some cases it might be desirable to produce
a standard additional to an existing one which was both “incremental” (in terms of language functionality) and
“secondary” (in terms of other requirements upon products).
3.5.3 Supplementary standards
In this Technical Report, a supplementary standard a
...