Секция 10: Структура программы и проблемы компиляции

1

[Полная структура программ и средств для раздельной компиляции описана в этой секции. A program is a set of partitions, each of which may execute in a separate address space, possibly on a separate computer.

1.a

Элемент глоссария: {Программа [Program]} Программа [program]  - набор разделов [partitions], каждый из которых может исполнятся в отдельном адресном пространстве, возможно на отдельном компьютере. Раздел состоит из ряда библиотечных модулей..

1.b

Элемент глоссария: {Раздел [Partition]} Раздел [partition] - часть программы. Каждый раздел состоит из набора библиотечных модулей. аждый раздел может выполнятся в отдельном адресном пространстве, возможно на отдельном компьютере. Программа может состоять только из одного раздела. Распределенная программа обычно содержит много разделов, которые могут испольнятся одновременно.

2

{Библиотечный модуль [library unit] (неформальное введение)} {библиотечный_элемент [library_item] (неформальное введение)} {библиотека [library] (неформальное введение)} Как объясняется ниже, раздел состоит из библиотечных модулей [library units]. интаксически, декларация библиотечного модуля это библиотечный_елемент [library_item], как тело библиотечного модуля.. Реализация может поддерживать понятие программной библиотеки [program library] (или просто “библиотеки”  [“library”]), которая содержит несколько библиотечных_елеметнов [library_items] и их подмодули. {программная библиотека [program library]: См. библиотека [library]} Библиотечные модули могут быть организованы в виде иерархии детей, внуков, и так далее.]

3

Эта секция содержит два подраздела: 10.1, “Раздельная компиляция” в которой обсуждается компиляция и проблемы раздельной компиялции связааные с ней. 10.2, “Выполнение программы” в которой обсуждаются понятия традиционно называемые как “линковка” и “выполнение” - процессы построения и выполнения разделов.

Принцыпы дизайна языка

3.a

{avoid overspecifying environmental issues} We should avoid specifying details that are outside the domain of the language itself. The standard is intended (at least in part) to promote portability of Ada programs at the source level. It is not intended to standardize extra-language issues such as how one invokes the compiler (or other tools), how one's source is represented and organized, version management, the format of error messages, etc.

3.b

{безопасная раздельная компиляция [safe separate compilation]} {раздельная компиляция (безопасная) [separate compilation (safe)]} The rules of the language should be enforced even in the presence of separate compilation. Using separate compilation should not make a program less safe.

3.c

{legality determinable via semantic dependences} It should be possible to determine the legality of a compilation unit(модуль компиляции) by looking only at the compilation unit(модуль компиляции) itself and the compilation units(модуль компиляции) upon which it depends semantically. As an example, it should be possible to analyze the legality of two compilation units(модуль компиляции) in parallel if they do not depend semantically upon each other.

3.d

On the other hand, it may be necessary to look outside that set in order to generate code — this is generally true for generic instantiation and inlining, for example. Also on the other hand, it is generally necessary to look outside that set in order to check Post-Compilation Rules.

3.e

See also the “generic contract model” Language Design Principle of 12.3, “Generic Instantiation”.

Формулировка изменений по сравнению с Ада83

3.f

The section organization mentioned above is different from that of RM83.