Справочное руководство по языку Ада-83
         

Структура программы и результат компиляции


В этой главе описываются общая структура программы и средства раздельной компиляции. Программа представляет собой набор из одного или нескольких компилируемых модулей, подаваемых на вход компилятора в виде одной или нескольких компиляций. Каждый компилируемый модуль определяет раздельную компиляцию некоторой конструкции. Ею может быть описание или тело подпрограммы, описание или тело пакета, описание или тело настраиваемого модуля или же конкретизация настройки. Кроме того, компилируемый модуль может быть субмодулем, т.е. телом подпрограммы, пакета, задачи, или настраиваемым модулем, описанным внутри другого компилируемого модуля.

Ссылки: задача 9, компилируемый модуль 10.1, компиляция 10.1, конкретизация настройки 12.3, настраиваемое тело 12.2, описание настройки 12.1, описание пакета 7.1, описание подпрограммы 6.1, субмодуль 10.2, тело задачи 9.1, тело пакета 7.1, тело подпрограммы



Компилируемые модули. Библиотечные модули


Текст программы может подаваться на вход компилятора в виде одной или нескольких компиляций. Каждая компиляция представляет собой последовательность компилируемых модулей.

компиляция ::= (компилируемый-модуль)компилируемый-модуль ::= спецификатор-контекста библиотечный-модуль | спецификатор-контекста вторичный-модульбиблиотечный-модуль ::= описание-подпрограммы | описание-пакета | описание-настройки | конкретизация-настройки | тело-подпрограммывторичный-модуль ::= тело-библиотечного-модуля | субмодультело-библиотечного-модуля ::= тело-подпрограммы | тело-пакета

Говорят, что компилируемые модули программы принадлежат программной библиотеке.


Компирируемый модуль определяет библиотечный модуль или вторичный модуль. Вторичный модуль — это раздельно компилируемое соответствующее тело библиотечного модуля или субмодуль другого компилируемого модуля. Обозначением раздельно компилируемой подпрограммы (библиотечного модуля или субмодуля) должен быть идентификатор. В программной библиотеке простые имена всех библиотечных модулей должны быть различными идентификаторами.

Результат компилирования библиотечного модуля состоит в том, чтобы определить (или переопределить) его как модуль программной библиотеки. По правилам видимости каждый библиотечный модуль рассматривается как описание, приведенное непосредственно внутри пакета STANDARD.

Результат компилирования вторичного модуля состоит в том, чтобы определить тело библиотечного модуля или в случае субмодуля соответствующее тело программного модуля, описанного внутри другого компилируемого модуля.

Тело подпрограммы в качестве компилируемого модуля рассматривается как вторичный модуль в том случае, если программная библиотека уже содержит библиотечный модуль, который является подпрограммой с тем же именем. В противном случае оно рассматривается одновременно и как библиотечный модуль, и как соответствующее этому библиотечному модулю тело (т.е. как вторичный модуль).

Компилируемые модули одной компиляции транслируются в заданном порядке. Относящаяся ко всей компиляции прагма должна помещаться перед первым компилируемым модулем компиляции.

Подпрограмма, являющаяся библиотечным модулем, может использоваться в качестве главной программы в традиционном смысле. Главная программа выполняется так, как будто она вызвана некоторой внешней задачей, средства инициализации этого выполнения языком не предписаны. Реализация может предъявить определенные требования к параметрам и результату (если он есть) главной программы (эти требования должны быть приведены в приложении F). Каждая реализация должна разрешать задание в качестве главной программы процедуры без параметров. Любая главная программа должна быть подпрограммой — библиотечным модулем.

Примечание. Простая программа может состоять из одного компилируемого модуля. Компиляция может не содержать ни одного компилируемого модуля, например ее текст может состоять из одних прагм.

Обозначение библиотечной функции не может быть знаком операции, но для переименования библиотечной функции в операцию допускается использование описания переименования. Две библиотечные подпрограммы должны иметь различные простые имена и потому не могут быть совмещены друг с другом. Однако описания переименования могут определить совмещенные имена для таких подпрограмм; кроме того, с библиотечной подпрограммой можно совмещать локально описанную подпрограмму. Так как библиотечные модули рассматриваются как описания, приведенные непосредственно в пакете STANDARD, то для библиотечного модуля L может быть использовано расширенное имя STANDARD.L (если только имя STANDARD не скрыто).

Ссылки: библиотечный модуль 10.5, видимость 8.3, должно 1.6, допустимо 1.6, задача 9, знак операции 6.1, идентификатор 2.3, имя 4.3, конкретизация настройки 12.3, локальное описание 8.1, находится непосредственно в 8.1, окружение 10.4, операция 4.5, описание 3.1, описание настройки 12.1, описание пакета 7.1, описание переименования 8.5, описание подпрограммы 6.1, пакет STANDARD 8.6, параметр подпрограммы 6.2, подпрограмма 6, прагма 2.8, программный модуль 6, простое имя 4.1, процедура 6.1, скрытие 8, совмещение 6.6, 8.7, соответствующее тело 1, спецификатор контекста 1, тело пакета 7.1, тело подпрограммы 6.3, указывать

1. СПЕЦИФИКАТОРЫ КОНТЕКСТА. СПЕЦИФИКАТОРЫ СОВМЕСТНОСТИ

Для указания библиотечных модулей, имена которых используются в' компилируемом модуле, служит спецификатор контекста.

спецификатор-контекста ::= {спецификатор-совместности {спецификатор-использования}}спецификатор-совместности ::= with простое-имя-модуля {, простое-имя-модуля};

Имена в спецификаторе контекста должны быть простыми именами библиотечных модулей. В спецификаторе совместности допустимы простые имена любых библиотечных модулей. В спецификаторе использования допустимы простые имена только тех библиотечных пакетов, которые указаны в предшествующих спецификаторах совместности данного спецификатора контекста. В спецификаторе контекста недопустимы простые имена, введенные описанием переименования.

Спецификаторы совместности и использования в спецификаторе контекста библиотечного модуля применяются к этому библиотечному модулю и ко вторичному модулю, который определяет соответствующее тело (независимо от того, повторен ли такой спецификатор для вторичного модуля или нет). Аналогично для компилируемого модуля спецификаторы совместности и использования в спецификаторе контекста применяются к этому модулю и к его субмодулям (если они есть).

Библиотечный модуль, упомянутый в спецификаторе совместности, примененном к компилируемому модулю, видим непосредственно внутри этого компилируемого модуля, исключая случаи его скрытия; этот библиотечный модуль видим как описанный непосредственно в пакете STANDARD (см. 8.6).

Спецификаторы совместности задают зависимости между компилируемыми модулями, т.е. компилируемый модуль зависит от других библиотечных модулей, упомянутых в спецификаторе контекста. Зависимости между модулями учитываются при определении допустимогопорядка компиляции (и перекомпиляции) компилируемых модулей (см. разд. 10.3), а также при определении допустимого порядка предвыполнения компилируемых модулей (см. разд. 10.5).

Примечание. Внутри компилируемого модуля видимы библиотечные модули, упомянутые в спецификаторе совместности (исключая случаи их скрытия), следовательно, они могут использоваться как соответствующие программные модули. Так, в компилируемом модуле имя библиотечного пакета может быть дано в спецификаторе использования и служит для формирования расширенных имен; библиотечные подпрограммы можно вызывать; можно описать конкретизации библиотечного настраиваемого модуля.

Правила для спецификаторов совместности дают одинаковый результат как при упоминании имени библиотечного модуля один или несколько раз, в различных спецификаторах совместности, так и внутри заданного спецификатора совместности.

Пример 1. Главная, программа.

Ниже приведен пример главной программы, состоящей из одного компилируемого модуля — процедуры печати вещественных корней квадратного уравнения. Предполагается, что в программной библиотеке уже содержится предопределенный пакет TEXT-10 и заданный пользователем пакет REAL-OPERATIONS (содержащий определения типа REAL и пакетов REAL-10 и REAL-FUNCTIONS). Такие пакеты могут быть использованы и другими главными программами.

with TEXT_IO, REAL_OPERATIONS; use REAL_OPERATIONS;procedure QUADRATIC_EQUATION is А, В, С, D : REAL: use REAL_IO, -- обеспечивает прямую видимость GET и PUT для REAL TEXT_IO, -— обеспечивает прямую видимость NEW-LINE и PUT для строк REAL_FUNCTIONS; -— обеспечивает прямую видимость функции SORT begin GET(A); GET(B); GET(C); D := B**2 - 4.0*A*C; if D < 0.0 then PUT("lmaginary Roots."); else PUT("Real Roots : XI = "); PUT((-B - SQRT(D))/(2.0*A)); PUT(" X2 = "); PUT((-B + SQRT(D))/(2.0*A)); end if; NEW_LINE; end QUADRATIC_EQUATION;

Примечание к примеру. В спецификаторах совместности компилируемого модуля надо упоминать имена только тех библиотечных подпрограмм или пакетов, видимость которых действительно необходима внутри модуля. Нет необходимости (и не следует) упоминать имена других библиотечных модулей, используемых внутри модулей, перечисленных в этих спецификаторах совместности, кроме тех, которые используются непосредственно в данном компилируемом модуле. Например, в теле пакета REAL-OPERATIONS могут потребоваться некоторые элементарные операции, определенные в других пакетах. Но эти пакеты не надо упоминать в спецификаторе совместности процедуры QUADRATIC-EQUATION, так как в ее теле элементарные операции не вызываются непосредственно.

Ссылки: библиотечный модуль 10.1, видимость 8.3, вторичный модуль 10.1, главная программа 10.1, должно 1.6, допустимо 1.6, имя 4.1, компилируемый модуль 10.1, настраиваемое тело 12.2, настраиваемый модуль 12.1, непосредственная видимость 8.3, описание пакета 7.1, описание подпрограммы 6.1, пакет 7, пакет STANDARD 9.6, пред выполнение 3.9, программный модуль 6, простое имя 4.1, процедура 6.1, скрытие 8.3, спецификатор использования 8.4, субмодуль 10.2, тело пакета 7.1, тело подпрограммы 6.3, тип 3.3, экземпляр

2. ПРИМЕРЫ КОМПИЛИРУЕМЫХ МОДУЛЕЙ

Компилируемый модуль может быть расчленен на несколько компилируемых модулей. Например, рассмотрим следующую программу:

procedure PROCESSOR is SMALL : constant := 20; TOTAL : INTEGER := 0; package STOCK is LIMIT : constant := 1000; TABLE : array (1 .. LIMIT) of INTEGER; procedure RESTART; end STOCK; package body STOCK is procedure RESTART is begin for N in 1 .. LIMIT loop TABLE(N) := N; end loop; end; begin RESTART; end STOCK; procedure UPDATE(X : INTEGER) is use STOCK; begin ... TABLE(X) := TABLE(X) + SMALL; end UPDATE;begin STOCK.RESTART; -- переинициализация TABLE end PROCESSOR;

Приведенные ниже три компилируемых модуля определяют программу с результатом, эквивалентным результату предыдущего примера (пунктирные линии между модулями напоминают, что они не обязаны составлять единый текст).

Пример 2. Несколько компилируемых модулей.

package STOCK is LIMIT : constant := 1000; TABLE : array (1 .. LIMIT) of INTEGER; procedure RESTART; end STOCK;package body STOCK is procedure RESTART is begin for N in 1 .. LIMIT loop TABLE(N) := N; end loop; end; begin RESTART; end STOCK;with STOCK; procedure PROCESSOR is SMALL : constant := 20; TOTAL : INTEGER := 0; procedure UPDATEIX : INTEGER) is use STOCK; begin TABLE(X) := TABLE(X) + SMALL; end UPDATE;begin ... STOCK.RESTABT; —- nepeинициализация TABLE ... end PROCESSOR

Заметим, что в последней версии примера в пакете STOCK невидимы внешние идентификаторы, отличные от предопределенных (в пакете STANDARD). В частности, в нем не используются идентификаторы SMALL и TOTAL, описанные в процедуре PROCESSOR; в противном случае пакет STOCK нельзя выделить из процедуры PROCESSOR, как это сделано выше. С другой стороны, процедура PROCESSOR зависит от пакета STOCK и упоминает его в спецификаторе совместности. Поэтому пакет STOCK можно использовать в расширенном имени и спецификаторе использования.

Эти три компилируемых модуля могут быть организованы как одна или несколько компиляций. Например, возможно объединение в одной компиляции спецификации и тела пакета в указанном порядке.

Ссылки: видимость 8.3, идентификатор 2.3, компилируемый модуль 10.1, описание 3.1, пакет 7, пакет STANDARD 8.6, программа 10, спецификатор использования 8.4, спецификатор совместности 1, спецификация пакета 7.1, тело пакета



Оптимизация программы


Компиляторы могут осуществлять оптимизацию предвыполнения описаний и выполнения операторов. В частности, компилятор может оптимизировать программу, вычисляя определенные выражения помимо статических. Если какое-либо из таких выражений, статических или нет, при вычислении приводит к возбуждению исключения, то код этой части программы может быть заменен кодом возбуждения того же исключения; это справедливо для исключений, возбуждаемых при вычислении имен и простых выражений (см. также разд. 11.6).

Компилятор может определить, что некоторые операторы или подпрограммы никогда не будут выполняться, например, если их выполнение зависит от условия, имеющего значение FALSE. В таком случае соответствующие части объектного машинного кода могут быть опущены. Такое правило позволяет на уровне языка производить условную компиляцию.

Примечание. Выражение, вычисление которого может привести к возбуждению исключения, не обязательно представляет ошибку, если выражение находится в операторе или подпрограмме, которые никогда не выполняются. Компилятор может предупреждать программиста о потенциальной ошибке.

Ссылки: возбуждение исключения 11.1, выражение 4.7, вычисление 4.5, исключение 11, логическое значение FALSE 3, оператор 5, описание 3.1, подпрограмма 6, предвыполнение 3.9, программа 10, статическое выражение 4.9, условие



Порядок компиляции


Правила, определяющие порядок компилирования модулей, являются непосредственным следствием правил видимости и, в частности, того факта, что любой библиотечный модуль, упомянутый в спецификаторе контекста компилируемого модуля, видим в нем.

Компилируемый модуль должен компилироваться после всех библиотечных модулей, указанных в его спецификаторе контекста. Вторичный модуль, являющийся телом подпрограммы или пакета, должен компилироваться после соответствующего библиотечного модуля. Любой субмодуль родительского компилируемого модуля должен компилироваться после него.

Компилирование, при котором в компилируемом модуле обнаружена ошибка, считается неудавшимся и никак не влияет на программную библиотеку; то же самое относится и к перекомпиляции (никакой компилируемый модуль не может стать устаревшим вследствие такой перекомпиляции).

Порядок компилирования компилируемых модулей программы должен отвечать частичной упорядоченности, определенной приведенными выше правилами.

Аналогичные правила применяются при перекомпиляции. На компилируемый модуль потенциально влияет изменение любого библиотечного модуля, упомянутого в его спецификаторе контекста. На вторичный модуль потенциально влияет изменение соответствующего библиотечного модуля. На субмодуль потенциально влияет изменение родительского компилируемого модуля. В результате успешной перекомпиляции компилируемого модуля все компилируемые модули, на которые потенциально влияет данный, считаются устаревшими и должны перекомпилироваться, кроме тех, которые больше не нужны. Реализация может уменьшить стоимость перекомпиляции, если установит, что данные изменения не повлияли на модули, которые находились под потенциальным влиянием данного.

Перекомпилирование субмодулей некоторого модуля на сам этот модуль никакого влияния не оказывает. Изменения в теле подпрограммы или пакета не влияют на другие компилируемые модули (кроме субмодулей этого тела), так как эти компилируемые модули имеют доступ только к спецификации подпрограммы или пакета. В реализации допустимы описанные ниже отступления от этого правила, связанные с открытыми подстановками, некоторыми оптимизациями, осуществляемыми компилятором, и некоторыми аспектами реализации настраиваемых программных модулей.

• Если прагма INLINE применяется к описанию подпрограммы в спецификации пакета, то открытая подстановка возможна, только если тело пакета откомпилировано раньше модулей, вызывающих эту подпрограмму. В таком случае открытая подстановка создает зависимость вызывающего модуля от тела пакета; компилятор должен распознавать такую зависимость при определении необходимости перекомпиляции. Если вызывающий модуль компилируется раньше, чем тело пакета, то для таких вызовов прагма INLINE может игнорироваться компилятором (при этом может быть выдано предупреждение о невозможности открытой подстановки). То же относится и к раздельно компилируемой подпрограмме, к которой применяется прагма INLINE.

• С целью оптимизации реализация может компилировать несколько модулей данной компиляции, создавая при этом дальнейшие зависимости между этими компилируемыми модулями. Эти зависимости должны учитываться компилятором для определения необходимых перекомпиляций.

• Реализация может требовать, чтобы описание настройки и соответствующее тело были частями одной и той же компиляции независимо от того, раздельно ли компилируется настраиваемый модуль или он локален в другом компилируемом модуле. Реализация может также требовать, чтобы субмодули настраиваемого модуля были частью одной и той же компиляции.

Примеры порядка компиляции:

а. В примере 1 (см. 1) процедура QUADRATIC-EQUATION должна компилироваться после библиотечных пакетов TEXT-10 и REAL-OPERATIONS, так как они упомянуты в спецификаторе совместности процедуры.

б. В примере 2 (см. 2) тело пакета STOCK должно компилироваться после соответствующей спецификации пакета.

в. В примере 2 (см. 2) спецификация пакета STOCK должна компилироваться до процедуры PROCESSOR. С другой стороны, процедура PROCESSOR может компилироваться как до, так и после тела пакета STOCK.

г. В примере 3 (см. 1) процедура G должна компилироваться после пакета TEXT-10, так как этот пакет упомянут в спецификаторе совместности процедуры G. В то же время пакет TEXT-10 может компилироваться как до, так и после процедуры ТОР.

д. В примере 3 (см. 1) субмодули TRANSFORM и FACILITY должны компилироваться после главной программы ТОР. Субмодуль G должен компилироваться после его родительского модуля FACILITY.

Примечание. Для библиотечных пакетов из правил перекомпиляции следует, что тело пакета становится устаревшим после перекомпиляции соответствующей спецификации. Если новая спецификация пакета не требует задания тела (т. е. она не содержит описаний программных модулей), то перекомпиляции тела такого пакета не требуется. В любом случае устаревшее тело пакета не должно использоваться и поэтому может быть удалено из программной библиотеки.

Ссылки: библиотечный модуль 10.1, видимость 8.3, вторичный модуль 10.1, имя 4.1, компилируемый модуль 10.1, компиляция 10.1, локальное описание 8.1, настраиваемый модуль 12, настраиваемое тело 12.2, описание настройки 12.1, описание подпрограммы 6.1, пакет 7, переменная 1, прагма INLINE 2, предвыполнение 3.9, процедура 6.1, родительский модуль 10.2, соответствующее тело 3.9, спецификатор контекста 1, спецификатор совместности 1, спецификация пакета 7.1, спецификация подпрограммы 6.1, субмодуль 10.2, тело пакета 7.1, тело подпрограммы 6.3, тело процедуры 6.3, тип



Предвыполнение библиотечных модулей


Перед выполнением главной программы все библиотечные модули, необходимые для главной программы, и тела этих модулей (если они есть) предвыполняются. Такими библиотечными модулями являются модули, упомянутые в спецификаторах совместности для главной программы, ее тела и субмодулей, а также модули, упомянутые в спецификаторах совместности для этих библиотечных модулей, их тел и субмодулей, и т. д. вплоть до получения транзитивного замыкания.

Предвыполнение таких библиотечных модулей и их тел производится в соответствии с частичной упорядоченностью, определяемой спецификаторами совместности (см. 10.3). Кроме того, библиотечный модуль, упомянутый в спецификаторе контекста для субмодуля, должен быть предвыполнен до тела библиотечного модуля-предка этого субмодуля.

Порядок предвыполнения, отвечающий такому отношению упорядоченности, не всегда обеспечивает выполнение следующего требования: тело любого библиотечного модуля пред-выполняется прежде любого другого компилируемого модуля, при предвыполнении которого необходимо предвыполнение тела этого библиотечного модуля. Для указания необходимости более раннего предвыполнения тел библиотечных модулей используется прагма ELABORATE.

Эта прагма записывается в виде

pragma ELABORATE (простое-имя-библиотечного-модуля {, простое-имя-библиотечного-модуля });

Такие прагмы допустимы только непосредственно после спецификатора контекста компилируемого модуля (до следующего за ним библиотечного или вторичного модуля). Аргументы этой прагмы должны быть простыми именами библиотечных модулей, упомянутых в спецификаторе контекста, и каждый такой библиотечный модуль должен иметь соответствующее тело. Эта прагма указывает, что тело библиотечного модуля должно предвыполняться до данного компилируемого модуля. Если данный компилируемый модуль — субмодуль, то тело библиотечного модуля должно предвыполняться до тела библиотечного модуля-предка (субмодуля).

Программа неправильна, если не может быть найден необходимый порядок предвыполнения (т. е. если существуют циклические зависимости). Предвыполнение компилируемых модулей программы в остальных случаях осуществляется в некотором порядке, который не определен в языке.

Ссылки: аргумент прагмы 2.8, библиотечный модуль 10.1, в некотором порядке 1.6, вторичный модуль 10.1, главная программа 10.1, допустим 1.6, зависимость между компилируемыми ^модулями 10.3, имя 4.1, компилируемый модуль 10.1, неправильна 1.6, простое имя 4.1, специ-|фикатор контекста 1, спецификатор совместности 1, субмодуль 10.2, раздельная компиляция



Программная библиотека


Правила языка требуют, чтобы компилятор одинаковым образом обрабатывал программу, состоящую из нескольких компилируемых модулей (и субмодулей) или из одного компилируемого модуля. Должен быть предусмотрен библиотечный файл, содержащий информацию о компилируемых модулях программной библиотеки, в который могут включаться символьные таблицы и другая информация, относящаяся к предыдущим компиляциям.

Обычно входными данными для компилятора являются компилируемые модули (или модуль) и библиотечный файл. Последний используется для проверок и корректируется после успешного компилирования каждого из этих модулей.

Примечание. Для компилируемых модулей компиляции создается одна программная библиотека. Возможно существование различных программных библиотек; в языке не определены правила их именования — это обеспечивается окружением системы программирования.

Для создания программной библиотеки данной программы или данного семейства программ следует ввести команды. Эти команды могут разрешать использование модулей из других программных библиотек. Наконец, для запроса состояний модулей в программной библиотеке также следует ввести команды. Форма этих команд не задана в определении языка.

Ссылки: компилируемый модуль 10.1, порядок компиляции 10.3, программа 10.1, программная библиотека 10.1, спецификатор использования 8.4, спецификатор контекста 1, спецификатор совместности 1, субмодуль



Субмодули компилируемых модулей


Субмодули используются для раздельной компиляции соответствующего тела программного модуля, описанного в другом компилируемом модуле. Этот метод разделения программы позволяет разрабатывать программу иерархически.

след-тела ::= спецификация-подпрограммы is separate; | package body простое-имя-пакета is separate; | task body простое-имя-задачи is separate;субмодуль :: = separate (имя-родительского-модуля) соответствующее-тело

Использование следа тела в качестве тела программного модуля (подпрограммы, пакета, задачного модуля или настраиваемого модуля) допускается, только если след тела помещен непосредственно в теле библиотечного пакета или в разделе описаний некоторого компилируемого модуля.

В случае задания тела программного модуля следом тела требуется, чтобы субмодуль, содержащий соответствующее тело, был откомпилирован раздельно. В случае подпрограммы спецификации подпрограммы, данные в соответствующем теле и в следе тела, должны быть согласованы (см. 1).

Для каждого субмодуля задается имя родительского модуля, т.е. компилируемого модуля, содержащего соответствующий след тела. Если родительский модуль — библиотечный модуль, то он называется предком. Если родительский модуль сам является субмодулем, то его имя должно быть представлено расширенным именем, начинающимся простым именем библиотечного модуля-предка. Простые имена всех субмодулей, которые имеют одинакового предка, должны задаваться различными идентификаторами.

Видимость в соответствующем теле субмодуля — это видимость, которая была бы получена в месте задания следа тела (в родительском модуле), если бы спецификаторы совместности и использования субмодуля были добавлены к спецификатору контекста родительского модуля. Если родительский модуль сам является субмодулем, то это же правило используется для определения видимости в соответствующем теле родительского модуля.

Результатом предвыполнения следа тела является предвыполнение соответствующего тела субмодуля.

Примечание. Два субмодуля различных библиотечных модулей в одной и той же программной библиотеке могут иметь совпадающие идентификаторы. В этом случае их расширенные имена различны, так как различны простые имена библиотечных модулей и простые имена всех субмодулей одного предка данного библиотечного модуля. Средствами описаний пеименования могут быть введены для (различных) субмодулей совмещенные имена подпрограмм.

Библиотечный модуль, упомянутый в спецификаторе совместности субмодуля, может быть скрыт описанем (с тем же идентификатором), данным в соответствующем теле субмодуля. Более того, такой библиотечный модуль может быть скрыт описанием, данным в родительском модуле, так как библиотечный модуль рассматривается как описанный в пакете STANDARD; это, однако, не влияет на интерпретацию спецификаторов совместности, ибо в них могут быть упомянуты имена только библиотечных модулей.

Ссылки: библиотечный модуль 10.1, видимость 8.3, задача 9, задачный модуль 9.1, идентификатор 2.3, имя 4.1, компилируемый модуль 10.1, локальное описание 8.1, настраиваемое тело 12.2, настраиваемый модуль 12, непосредственная видимость 8.3, непосредственное вхождение 8.1, описание 3.1, описание переименования 8.5, пакет 7, подпрограмма 6, предвыполнение 3.9, программа 10, программный модуль 6, простое имя 4.1, раздел описаний 3.9, раздельная компиляция 10.1, расширенное имя 3, скрыт описанием 8.3, совмещение 8.3, согласованный 1, соответствующее тело 3.9, спецификатор использования 8.4, спецификатор контекста 1, спецификатор совместности 1, спецификация подпрограммы 6.1, тело задачи 9.1, тело пакета 7.1, тело подпрограммы

1. ПРИМЕРЫ СУБМОДУЛЕЙ

Сначала процедура ТОР оформлена в виде компилируемого модуля без субмодулей.

with TEXT_IO; procedure TOP is type REAL is digits 10; R, S ; REAL := 1.0; package FACILITY is PI : constant := 3.14159_26536; function F (X : REAL) return REAL; procedure G (Y, Z : REAL); end FACILITY; package body FACILITY is -— предшествуют некоторые локальные описания function F(X : REAL) return REAL is begin -— последовательность операторов функции F ... end F; procedure G(Y, Z : REAL) is -— использующие пакет TEXT_IO локальные процедуры ... begin -— последовательность операторов процедуры G ... end G;end FACILITY; procedure TRANSFORM(U : in out REAL) is use FACILITY; begin U := F(U); ... end TRANSFORM;begin -- TOP TRANSFORM(R); FACILITY.G(R, S); end TOP;

Тело пакета FACILITY и процедуру TRANSFORM можно представить в виде раздельно компилируемых субмодулей модуля ТОР. Тело процедуры G также может быть представлено как субмодуль модуля FACILITY.

Пример 3:

procedure TOP is type REAL is digits 10; R, S : REAL :== 1.0; package FACILITY is PI : constant := 3.14159_26536; function F (X : REAL) return REAL; procedure G (Y, Z : REAL); end FACILITY; package body FACILITY is separate; procedure TRANSFORM (U : in out REAL) is separate;begin -- TOP TRANSFORM(R); ... FACILITY.G(R, S): end TOP;separate (TOP) procedure TRANSFORM(L) : in out REAL) is use FACILITY; begin U := F(U); ... end TRANSFORM;separate (TOP) package body FACILITY is -— предшествуют некоторые локальные описания function F(X : REAL) return REAL is begin -- последовательность операторов функции F ... end F; procedure G (Y, Z : REAL) is separate; -- след тела Gend FACILITY;with TEXT_IO; separate (TOP.FACILITY) -- полное имя пакета FACILITY procedure G(Y, Z : REAL) is --использующие ТЕХТ_Ю локальные процедуры begin -- последовательность операторов процедуры G ... end G;

В этом примере TRANSFORM и FACILITYявляются субмодулями процедуры TOP, а G -субмодулем пакета FACILITY. Видимость в этом пакете такая же, как и в предыдущем, с одним отличием : TEXT_IO используется только в G, по этому соответствующий спецификатор совместности написан для G, а не для процедуры TOP. В остальном видимость идентификаторов в соответствующих телах программ обеих версий одинакова. Например, в соответствующем теле субмодуля G (непосредственно) видимы процедура TOP, тип REAL, переменные R и S, пакет FACILITY и содержащиеся в нем именнованое число PI и подпрограммы F и G.

Ссылки: видимость 8.3, идентификатор 2.3, именованное число 3.2, компилируемый мо-Идуль 10.1, локальное описание 8.1, пакет 7.1, переменная 1, подпрограмма 6, процедура 6, |след тела 10.2, соответствующее тело 3.9, спецификатор совместности 1, тело пакета 7.1, |тело процедуры 6.3, тип