この規格 プレビューページの目次
※一部、英文及び仏文を自動翻訳した日本語訳を使用しています。
序章
背景: 過去 30 年間 (1966 年から 2002 年) にわたって、多くのコンピューター プログラミング言語の標準が作成されてきました。起草委員会は、前任者の成功と過ちの両方から学ぶことで、ある程度専門性を高めましたが、それぞれが独自の言語を孤立して扱ってきました。
このテクニカル レポートの初版は 1980 年代に作成され、それまでに得られた経験の一部を一連のガイドラインにまとめ、プログラミング言語標準の起草委員会の作業を容易にするように設計されています。この第 2 版では、国際化と文字セットの分野におけるその後の経験と開発を考慮してガイドラインを強化しています。
このドキュメントは、テクニカル レポート タイプ 3 として発行されます。これは、プログラミング言語の設計 (したがって、その標準化に関連する要件) が依然としてかなり急速に進化しており、標準化されている言語と標準化されていない言語の両方が、その特性と特性において非常に大きく異なるためです。ガイドラインの標準セットとしてさえ、完全な標準として出版されたスタイルは、現時点では適切ではないように思われました.
ガイドラインの必要性: それぞれの言語は全体として独自のものですが、多くの言語、またはほとんどの言語に共通する個々の機能が多数あります。標準化は、言語とその標準の形式の両方において不可欠な多様性を阻害するべきではありませんが、不必要な多様性は避けたほうがよいでしょう。不必要な多様性は、不必要な混乱、不必要な再訓練、不必要な転換や再開発、不必要なコストにつながります。したがって、ガイドラインの目的は、言語間およびその標準間での標準化の達成を支援することです。
ガイドラインの存在により、起草委員会は多くの場合、他の言語について以前に議論された詳細な点について多くの議論をする必要がなくなります。
さらに、言語間の不必要な多様性を回避することで、プログラマーが言語間を簡単に切り替えることができます。
注記多様性は、標準の作成者と使用者の両方にとって、本質的な部分により適した時間とリソースを浪費するため、主要な問題です。言語標準の構築にはリソースが非常に高くつき、他の委員会が直面したのと同じ問題を最初から解決しようとして、「車輪の再発明」に多大な時間と労力が費やされます。
しかし、多くの異なる言語プロセッサのサポート環境 (オペレーティング システム機能、ユーティリティなど) を構築する (たとえば) タスクに直面するソフトウェア ライターは、最終的な標準からの多くの問題にも直面します。言語間の本質的な違いは別として、まずレイアウト、配置、用語、メタ言語などのバリエーションがあります。さらに悪いことに、基本的に同じ種類の要件間にも違いがあり、いくつかの実質的な違い、いくつかのわずかな違い、いくつかの違いがあります。微妙 - 指定された方法の不必要なバリエーションによって複雑になります。これは、基本的に同じタスクを実行するさまざまな言語にさまざまなサポート ツールを提供することの重複と同様に、計り知れない余分な負担を表しています。
このテクニカル レポートの使用方法: このテクニカル レポートは、プログラミング言語をどのように設計または標準化すべきかについて法制化しようとするものではありません。それを試みても無駄です。ガイドラインは、その名前が示すように、ガイダンスのみを目的としています。それにもかかわらず、起草委員会はそれらを真剣に検討し、それぞれを注意深く検討し、実行可能な場合はその勧告を採用するよう強く求められています.ガイドラインは、ほとんどの場合、特定のプログラミング言語標準が特定のガイドラインに従って作成されているかどうかを調べることによって判断できるように作成されています。ただし、そのような評価から導き出される結論、およびその結果として取られるべき措置は、このテクニカル レポートの個々のユーザーの問題であり、その範囲を超えています。
特定のガイドラインを採用しない理由は、文書化して利用可能にする必要があります (たとえば、プログラミング言語標準の有益な付属書で)したがって、これとその理由は、プログラミング言語標準またはこのテクニカル レポートの将来の改訂で考慮に入れることができます。
もちろん、これらのガイドラインに従うときは、ISO/IEC 指令や、規格が作成されている方向の下にある標準化団体のその他の規則と矛盾しない方法でそうするように注意を払う必要があります。
その他の関連ガイドライン: このテクニカル レポートは、プログラミング言語の一般性と、プログラミング言語の標準化の問題に関する一般的な問題に関係しており、すべての状況ですべての言語に必ずしも普遍的に適用できるとは主張されていません。特定の言語または言語の種類、または特定の関心領域については、このテクニカル レポートに適切なガイドラインよりも詳細で具体的なガイドラインが必要になる場合があります。発行の時点で、いくつかの特定の領域は、既存または今後のテクニカル レポートに記載されている、より詳細なガイドラインの対象となっています。そのようなテクニカル レポートは、特定の問題や適用分野をカバーするために、このテクニカル レポートのガイドラインを拡張、解釈、または適応させる場合があります。このテクニカル レポートのユーザーは、状況に応じて、このテクニカル レポートのガイドラインだけでなく、他のガイドラインも考慮することをお勧めします。特に、ISO/TR 9547 および ISO/IEC TR 10034 を参照してください。
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.
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.