ISO/IEC TR 10176:2003
(Main)Information technology — Guidelines for the preparation of programming language standards
Information technology — Guidelines for the preparation of programming language standards
ISO/IEC TR 10176:2003(E) provides guidelines for the preparation of Programming Language Standards. Standards for programming languages are developed by many committees from many countries, with many different editors supporting the effort. ISO thus considered it necessary to develop guidelines so that these standards cover at least the following subjects: Consistent terminology Consistent structure Syntax and semantics Error and exception handling Provisions of options Presentation of source programs Processor dependences Binding strategies to functional standards Conformance definition Internationalization and support of multiple languages Cultural convention related functionality Use of expanded character repertoire for identifiers User documentation The constant additions to ISO/IEC 10646, the Universal character set, necessitate timely updates of ISO/IEC TR 10176 to allow the use of local scripts and characters in programming languages. Annex A of ISO/IEC TR 10176:2003 provides such an expanded collection of characters, recommended for use in programming languages.
Technologies de l'information — Lignes directrices pour la préparation des normes des langages de programmation
General Information
Relations
Standards Content (Sample)
TECHNICAL ISO/IEC
REPORT TR
10176
Fourth edition
2003-04-15
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:2003(E)
©
ISO/IEC 2003
---------------------- Page: 1 ----------------------
ISO/IEC TR 10176:2003(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 2003
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2003 — All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC TR 10176:2003(E)
Contents Page
Foreword. iv
Introduction . v
1 Scope. 1
2 Normative references. 1
3 Terms and definitions. 1
4 Guidelines. 7
4.1 Guidelines for the form and content of standards .7
4.1.1 Guideline: The general framework . 7
4.1.2 Guideline: Definitions of syntax and semantics. 8
4.1.3 Guidelines on the use of character sets. 8
4.1.4 Guideline: Error detection requirements. 14
4.1.5 Guideline: Exception detection requirements . 17
4.1.6 Guideline: Static detection of exceptions . 19
4.1.7 Guideline: Recovery from non-fatal errors and exceptions . 20
4.1.8 Guideline: Requirements on user documentation . 20
4.1.9 Guideline: Provision of processor options . 20
4.1.10 Guideline: Processor-defined limits . 22
4.2 Guidelines on presentation. 23
4.2.1 Guideline: Terminology. 23
4.2.2 Guideline: Presentation of source programs. 24
4.3 Guidelines on processor dependence. 24
4.3.1 Guideline: Completeness of definition . 24
4.3.2 Guideline: Optional language features . 24
4.3.3 Guideline: Management of optional language features . 24
4.3.4 Guideline: Syntax and semantics of optional language features . 25
4.3.5 Guideline: Predefined keywords and identifiers . 25
4.3.6 Guideline: Definition of optional features . 25
4.3.7 Guideline: Processor dependence in numerical processing . 26
4.4 Guidelines on conformity requirements. 26
4.5 Guidelines on strategy. 26
4.5.1 Guideline: Secondary standards. 26
4.5.2 Guideline: Incremental standards . 26
4.5.3 Guideline: Consistency of use of guidelines . 27
4.5.4 Guideline: Revision compatibility. 27
4.6 Guidelines on cross-language issues . 29
4.6.1 Guideline: Binding to functional standards . 29
4.6.2 Guideline: Facilitation of binding . 29
4.6.3 Guideline: Conformity with multi-level functional standards. 30
4.6.4 Guideline: Mixed language programming . 30
4.6.5 Guideline: Common elements . 30
4.6.6 Guideline: Use of data dictionaries. 30
4.7 Guidelines on Internationalization . 30
4.7.1 Guideline: Cultural convention set switching mechanism. 30
4.7.2 Guideline: Cultural convention related functionality .31
Annex A (informative) Recommended extended repertoire for user-defined identifiers. 32
© ISO/IEC 2003 — All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC TR 10176:2003(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
In exceptional circumstances, the joint 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 the joint 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.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 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 fourth edition cancels and replaces the third edition (ISO/IEC 10176:2001), which has been technically
revised.
iv © ISO/IEC 2003 — All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC TR 10176:2003(E)
Introduction
Background: Over the last three decades (1966-2002), 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. This second edition enhances the guidelines to take into
account subsequent experiences and developments in the areas of internationalization and character sets.
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 2003 — All rights reserved v
---------------------- Page: 5 ----------------------
ISO/IEC TR 10176:2003(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 2003 — All rights reserved
---------------------- Page: 6 ----------------------
TECHNICAL REPORT ISO/IEC TR 10176:2003(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 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO/IEC 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/IEC 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:2001, 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 metalanguage — Extended BNF
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
© ISO/IEC 2003 — All rights reserved 1
---------------------- Page: 7 ----------------------
ISO/IEC TR 10176:2003(E)
This clause contains terminology which is used in particular specialized senses in this Technical Report. 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/IEC 2382-15; the
terminology defined here, itself divergent in some cases from that in ISO/IEC 2382-15, has been introduced to
minimize confusion which might result from such difference. Some remarks are made below about particular
divergences from ISO/IEC 2382-15, for further clarification.
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/IEC 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/IEC 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/IEC 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).
2 © ISO/IEC 2003 — All rights reserved
---------------------- Page: 8 ----------------------
ISO/IEC TR 10176:2003(E)
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.
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/IEC 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).
© ISO/IEC 2003 — All rights reserved 3
---------------------- Page: 9 ----------------------
ISO/IEC TR 10176:2003(E)
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.
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 sta
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.