ISO/IEC TR 10176:1991
(Main)Information technology — Guidelines for the preparation of programming language standards
Information technology — Guidelines for the preparation of programming language standards
Technologies de l'information — Lignes directrices pour la préparation des normes et des langages de programmation
General Information
Relations
Standards Content (Sample)
TECHNICAL
REPORT
1991 -04-1 5
Information technology - Guidelines for the
ing language standards
preparation of programi
Technologies de I'information - Lignes i xtrices pour la préparation des normes
des langages de programmation
Reference number
ISO/IEC TR 10176 : 1991 (E)
---------------------- Page: 1 ----------------------
ISO/IEC TR 10176 : 1991 (E)
Contents
page
iv
Foreword .
V
Introduction .
V
Background .
The need for guidelines . V
How to use this Technical Report . vi
Further related guideline6 . vi
1 scope . 1
1
2 References .
3 Definitions . 1
1
3.1 Programming language processor .
3.2 Syntax and semantics . 2
2
3.3 Errors, exceptions, and conditions .
3.3.1 Errors . 2
3.3.2 Exceptions . 2
3.3.3 conditions . 2
3.3.4 Relationship to other terminology . 2
3.4 Processor dependence . 3
3
3.5 Secondary, incremental and supplementary standards .
3.5.1 Secondary standards . 3
3
3.5.2 Incremental standards .
3.5.3 Supplementary standards . 4
4 Guidelines .
4
4.1 Guidelines for the form and content of standards . 4
4.1.1 Guideline: The general framework . 4
4.1.2 Guideline: Definitions of syntax and semantics . 5
4.1.3 5
Guidelines on the use of character sets .
4.1.3.1 Guideline: Character sets used for wwram text . . 6
4.1.3.2 Guideline: Character sets used in chakter literals 6
4.1.3.3 Guideline: Character sets used in comments . 7
7
4.1.3.4 Guideline: Character sets used for data .
4.1.3.5 Guideline: Collating sequences . 7
4.1.3.8 Guiine: Use of other character sets. . 8
4.1.4 Guideline: Error detection requirements . 8
4.1.4.1 9
Checklist of potential errors .
10
4.1.5 Guideline: Exception detection requirements .
11
4.1.5.1 Checklist of potential exceptions .
4.1.6 Guideline: Static detection of exceptions . 13
4.1.7 Guideline: Recovery from non-fatal errm and exceptions 13
13
4.1.8 Guideline: Requirements on user documentation .
4.1.9 Guideline: Provision of processor options . 14
4.1 9.1 Checklist of potential processor options . 14
4.1.10 Guideline: Processordefined limits . 15
4.1.10.1 Checklist of potential processordefined limits . 16
4.1.10.2 Actual values of limits . 16
4.2 Guidelines on presentation . 17
17
4.2.1 Guideline: Terminology .
17
4.2.2 Guiiline: Presentation of source programs .
O ISO/IEC 1991
All rights reserved . No part of this publication may be reproduced or utilized in any form or by any
means. electronic or mechanical. including photocopying and microfilm. without permission in
writing from the publisher .
ISO/IEC Copyright Office O Case postale 56 O CH-1211 Genbve 20 O Switzerland
Printed in Sditzerland
ii
---------------------- Page: 2 ----------------------
ISO/IEC TR 10176 : 1991 (E)
4.3 Guidelines on processor dependence . 17
4.3.1 Guideïi: Completeness of definition . 17
4.3.2 Guideline: Optional language features . 18
4.3.3 Guideline: Management of optional language features . 18
Guideline: Syntax 8 semantics of optional language features 18
4.3.4
4.3.5 GuKteline: Predefined keywords and identifiers . 18
4.3.6 Guideline: Definition of optional features . 19
4.3.7 Guideline: Processor dependence in numerical processing 19
19
4.4 Guidelines on mfomiity requirements .
20
4.5 GuKleiines on strategy .
4.5.1 Guideline: Secondary standards . 20
4.5.2 Guideline: Incremental standards . 20
4.5.3 Guideline: Consistency of use of guidelines . 20
4.5.4 Guideline: Revision compatibility . 20
4.5.4.1 Classification of types of change . 21
4.5.4.2 Difficulty of converting affected programs . 21
23
4.6 Guidelines on cross-language issues .
4.6.1 Guideline: Binding to functional standards . 23
4.6.2 Guideline: Facilitation of binding . 23
4.6.3 Guideline: Conformity with multi-level functional standards 23
4.6.4 Guideline: Mixed language programming . 23
4.6.5 Guideline: Common elemenb . 24
4.6.6 Guideline: Use of data didonaries . 24
Index . 25
iii
---------------------- Page: 3 ----------------------
ISO1IEC TR 10176 : 1991 (E)
Foreword
IS0 (the International Organization for Standardization) and IEC (the International
Electrotechnical Commission) form the specialized system for worldwide standardiz-
ation. National bodies that are members of IS0 or IEC participate in the development
of International Standards through technical committees established by the respective
organization to deal with particular fields of technical activity. IS0 and IEC technical
committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with IS0 and IEC, also take part in the
work.
In the field of information technology, IS0 and IEC have established a joint technical
committee, ISO/IEC JTC 1.
The main task of technical committees is to prepare International Standards. In excep-
tional 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 publi-
cation, 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.
ISO/IEC TR 10176, which is a Technical Report of type 3, was prepared by Joint
Technical Committee ISO/IEC JTC 1, lnformation technology.
---------------------- Page: 4 ----------------------
ISO/IEC TR 10176 : 1991 (E)
Introduction
Background: Over the last 20 years and more (1966-1989), 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 time is now right to put together some of the experience that has been
gained, in a set of guidelines, designed to ease the task of drafting committees of
programming language standards.
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,
so greatly in their properties and
both standardized and unstandardized, vary
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 shouid 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 resourœs
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 fad.
However, a software writer faced with the task of building (say) a support
environment (operating system faaiities, utilities, etc.) for a number of different
language processors is also faced with many problems from the eventual
standards. Quite apart from the essentiai differences beween the languages, there
am to begin with the variations of layout, arrangement, termindogy,
metalanguages, etc. Much worse, there are the variations beween requirements
of basically the same kind, some substantial, some slight, some subtle -
compounded by needless variaiions in the way they are specified. Thii represents
burden - as does the duplication in providing different support
an immense extra
toois for different languages performing basically the same task.
V
---------------------- Page: 5 ----------------------
ISO/IEC TR 10176 : 1991 (E)
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 oniy. 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 recorded and made
available (e.g. in the minutes of the meeting at which use of the guideline was
considered but rejected) so thaî they may be taken into account when a new
Technical Report on this subject is deemed necessary.
of course, care must naturally be taken when following these guidelines to do so
in a way which does not conflict with the ISOAEC 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 ISOllEC TR 10034.
vi
---------------------- Page: 6 ----------------------
ISO/IEC TR 10176 : 1991 (E)
TECHNICAL REPORT
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
646:1983 Information processing - IS0 7-bit coded character set for informatbn interchange.
It. SO 2382-15:1985, Data processing systems - Vocabulary - Part 15: Programming languages.
IS0 4873:1986, Information processing - IS0 8-bit code for information interchange - Structure and rules for
implementation.
IS0 6937-2:1983, Information processing - Coded character sets for text communication - Part 2: Latin
alphabetk and non-alphabetfc graphic characters.
IS0 8859:1987, Information processing - 8-bit single byte coded graphic character sets.
ISO/TR 9547:1988, Prqramming language processors - Test methods - Guidelines for their development
and acceptability.
ISOAEC TR 10034:1990, Guidelines for the preparation of conformity clauses in programming language
standards.
BS 6154:1981, Method of defining syntactk metalanguage.
3 Definitions
's clause contains terminology which is used in particular specialized senses in this Technical Report. It is
claimed that all language standards necessarily use the terminology in the senses defined here; where
4 propriate, 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 IS0 2382-15; the
terminology defined here, itself divergent in some cases from that in IS0 2382-15, has been introduced to
minimize confusion which might result from such differences. Some remarks are made below about
particular divergences from IS0 2382-1 5, 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.
NOTES
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.
2 In lSO/TR 9547 the term "processor" is used in a more restricted sense. For the purposes of lSO/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
ISOiTR 9547 has to be made in this Technical Report.
1
---------------------- Page: 7 ----------------------
iSO/IEC TR 10176 : 1991 (E)
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
by inspection of a program text, with a
"context-free", but must allow a processor to decide, solely
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.
"pertaining to properties that can be
NOTE - In Is0 2382-15 the term static is defined (15.02.09) as
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. Is0 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 Is0 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 acroes 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, and conditions
3.3.1 errors: The incorrect program constructs which are statically determinable solely from inspection of s
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 nor 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.
NOTES
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 aiter 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.
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 languagedefined or
userdefined 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.
IS0 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". ONconditions in PU1 and
---------------------- Page: 8 ----------------------
ISO/IEC TR 10176 : 1991 (E)
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 diffiiuk 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 ONcondlions being enabled or disabled
(globally or iocaiiy), 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 processordependent, 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 processordeflned, this means that its definition is lefi
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).
NOTES
1 The term "feature" is used here to encompass both language features (syntactic elements a change to which
would diange 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, processordependent or processordefined are the collating sequence of the supported
character set (a language feature) and processor action on detection of an exception (a processor feature).
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.
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 processordefined 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 requiremenis 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
em 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
---------------------- Page: 9 ----------------------
ISO/IEC TR 10176 : 1991 (E)
3.5.3 Supplementary standards
In this Technical Report, a Supplementary standard adds functionality to an existing standard without
extending its range of syntactic constructs; such as by the binding of a language to a specific set of
functions. Supplementary standards are expected to be expressed in terms of the base language which they
supplement, but do not replace any elements of the primary standard.
4 Guidelines
4.1 Guidelines for the form and content of standards
4.1.1 Guideline: The general framework
The standard should be designed so that it consists of at least the following elements:
1) The specification of the syntax of the language, including rules for conformity of programs and
processors.
2) The specification of the semantics of the language, including rules for conformity of programs
and processors.
3) The specification of all further requirements on standard-conforming programs, and of rules for
conformity.
4) The specification of all further requirements on standardconforming processors (such as error
and exception detection, reporting and processing; provision of processor options to the user;
documentation; validation; etc.), and of rules for conformity.
5) One or more annexes containing an informal description of the language, a description of the
metalanguage used in 1) and any formal method used in 2), a summary of the metalanguage
definitions, a glossary, guidelines for programmers (on processor-dependent features, documentation
available, desirable documentation of programs, etc.), and a cross-referenced index to the
document.
6) An annex containing a checklist of any implementation-defined features.
7) An annex containing guidelines for implementors, including short examples.
8) An annex providing guidance to users of the standard on questions relating to the validation of
TR 10034, and any specific requirements relating to
conformity, with particular reference to ISO/IEC
validation contained in 1) to 4) above.
9) In the case where a language standard is a revision of an earlier standard, an annex containing
a detailed and precise description of the areas of incompatibility between the old and the new
standard.
10) An annex which forms a tutorial commentary containing complete exampie programs that
illustrate the use of the language.
NOTES
1 The objective of this guideline is to provide a framework for use by drafting committees when producing
standards documents. This framework ensures that users of the standard, whether programmers, implementors
or testers, will find in the standards document the things that they are looking for; in addition, it provides drafting
committees with a basis for organizing their work.
2 The elements referred to above are concerned only with the technical content of the standard, and are to be
regarded as iogicai elements of that content rather than necessarily physical elements (see note 4 below).
3 It is to be made clear that the annexes referred to in elements 5) to 10) above are informative annexes (i.e.
descriptive or explanatory only), and not normative, i.e. do not qualify or amend the specific requirements of the
standard given in elements l), 2), 3) and 4). It should be explicitly stated that, in any case of ambiguity or
conflict, it is the standard as specified in elements l), 2), 3) and 4) that is definitive. Note that, if a definition
(as opposed to description) of any formal method used in elements 1) and 2) cannot be established by
reference, then the standad may need to incorporate that definition, insofar as is allowed by the rules of the
responsible standards body (see also 4.1.2).
4
---------------------- Page: 10 ----------------------
iSO1iEC TR 10176 : 1991 (E)
4 Given the requirements of note 3 above, a drafting committee has the right to interleave the various elements
of the standard it is producing if it feels that this has advantages of ciariîy and readability, provided that
precision is not compromised thereby, and that the distinction beiween the nonnative (specification) elements
and the informative (informal descriptive) dements is everywhere made dear.
5 Element 9) will be empty if the standard is not a revision of an earlier standard. No specific guidelines or
recommendations are included in this Technical Report concerning requirements on programs other than
conformity with the syntactic and semantic rules of the language, and if this is the case in a standard, element
3) will be empty; however, it is recommended that in such a case an explicit statement be included that the only
rules for conformity of programs are those for conhity with the language definition. It is recommended that
none of the other elements should be leR empty.
2 Guideline: Definitions of syntax and semantics
Consideration should be given to the use of a syntactic metalanguage for the formal definition of the syntax
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.