Правила видимости
В этой главе описаны правила, определяющие область действия описания, и правила, определяющие видимость идентификаторов в различных точках текста программы. Формулировка правил видимости использует понятие зоны описания.
Ссылки: видимость 8.3, зона описания 8.1, идентификатор 2.3, область 8.2, описание
Контекст разрешения совмещения
Совмещение определено для программ, литералов перечисления, символов операций и одиночных входов, а также для тех операций, которые присущи обычным базовым операциям, например присваивание, проверка принадлежности, генератор, литерал null, агрегаты и строковые литералы.
Для совмещенных понятий разрешение совмещения определяет фактический смысл, который имеет вхождение идентификатора, когда в соответствии с правилами видимости выясняется, что в месте этого вхождения приемлема более чем одна трактовка идентификатора;аналогичным образом разрешение совмещения определяет фактическую трактовку вхождения операции или некоторой базовой операции.
В таком месте рассматриваются все видимые описания. Вхождение правильно только тогда, когда есть точно одна интерпретация самого вложенного полного контекста. Полный контекст — это описание, оператор, спецификатор представления.
При рассмотрении возможных интерпретаций полного контекста учитываются только те правила, которые касаются синтаксиса, области действия и видимости, а также те, которые даны ниже. Учитываются:
а) любое правило, которое требует, чтобы имя или выражение имели определенный тип или такой же тип, как другое имя или выражение;
б) любое правило, которое требует, чтобы тип имени или выражения был типом определенного класса; аналогично любое правило, которое требует, чтобы определенный тип был дискретным, целым, вещественным, универсальным, символьным, логическим или нелимитируемым типом;
в) любое правило, которое требует, чтобы префикс соответствовал определенному типу;
г) любое правило, которое задает определенный тип в качестве типа результата базовой операции, и любое правило, которое устанавливает, что это тип определенного класса;
д) правила, которые требуют, чтобы тип агрегата или строкового литерала был определен исключительно охватывающим полным контекстом (см. 4.3 и 4.2). Аналогично правила, которые требуют, чтобы тип префикса атрибута, тип выражения оператора выбора или тип операнда преобразования типа были определены независимо от контекста (см. 4, 4.6, 5.4 и 1);
е) правила, данные в разд. 6.6 по разрешению вызовов совмещенных подпрограмм, в разд. 4.6 по неявным преобразованиям универсальных выражений, в разд. 1 по интерпретации дискретных диапазонов с границами, имеющими универсальный тип, в разд. 3 по интерпретации расширенного имени, чей префикс обозначает подпрограмму или оператор принятия.
Имена подпрограмм, используемые в качестве аргументов прагмы, следуют другому правилу: прагма может применяться для нескольких совмещенных подпрограмм, как пояснено в разд. 2 для прагмы INLINE, в разд. 11.7 для прагмы SUPPRESS и в разд. 13.9 для прагмы INTERFACE.
Подобно данные в спецификаторах контекста (см. 1) и спецификаторах адреса простые имена следуют другим правилам.
Примечание. Если существует только одна возможная интерпретация, то идентификатор обозначает соответствующее понятие. Однако данное утверждение не означает, что это вхождение обязательно правильно, так как существуют другие требования, которые не учитываются при разрешении совмещения: например, являетсятти выражение статическим, каковы виды параметров, является ли объект константой, выполняются ли правила согласования, является ли вхождение в спецификатор представления предписывающим, каков порядок предвыполне-ния и т. п.
Аналогично при разрешении совмещения не учитываются подтипы. (Нарушение ограничения не делает программу неправильной, но возбуждает исключение во время выполнения программы.)
Спецификация параметра цикла есть описание и, следовательно, полный контекст.
Правила, которые требуют, чтобы определенные конструкции имели один и тот же профиль параметров и типа результата, подпадают под категорию а); то же справедливо для правил, которые требуют согласования двух конструкций, так как это согласование требует в свою очередь, чтобы соответствующие имена имели одинаковый смысл, определенный правилами видимости и совмещения.
Ссылки: агрегат 4.3, базовая операция 3.3, вход 9.5, выражение 4.4, генератор 4.8, идентификатор 2.3, имя 4.1, исключение 11, класс типа 3.3, литерал 4.2, литерал перечисления 1, литерал null 3.8, оператор 5, оператор выбора 5.4, операция 4.5, операция типа 3, описание 3.1, подпрограмма 6, подтип 3.3, правильный 1.6, прагма 2.8, преобразование типа 4.6, присваивание 5.2, проверка принадлежности 2, раздел формальных параметров G.1, совмещение6.6, спецификатор представления 13.1, спецификация параметра цикла 5.5, статическое выражение 4.9, статический подтип
Правила формы (а): выбор 3, 2, 5.4, выражение по умолчанию 3.7, 1, 6.1, 1, выражение результата 5.8, дискретный диапазон 1, 5.5, 9.5, индексное выражение 1, 2, 9.5, квалифицированное выражение 4.7, начальное значение 1, ограничение диапазона 3.5, ограничение дискриминанта 2, ограничение индекса 1, оператор задержки 9.6, переименование объекта 8.5, правила согласования 9.5, присваивание 5.2, проверка принадлежности 2, профиль параметров и типа результата 8.5, 6, сопоставление компонент 1, 2, сопоставление параметров настройки 12.3, сопоставление параметров 1, спецификатор адреса 13.5, спецификатор представления перечислимых
Правила формы (б): атрибут VAL 5, выражение выбора 6.4, дискретный диапазон 1, 5.5, 9.5, именуемая компонента 3, оператор прекращения 9.10, описание плавающего типа 7, описание фиксированного типа 9, описание целого типа 4, описание числа 2, присваивание 5.2, проверка принадлежности 4.4, спецификатор длины 13.2, спецификатор представления записи 13.4, условие 5.3, 5.5, 5.7, 1, форма управления промежуточной проверкой
Правила формы (в): именуемая компонента 3, индексируемая компонента 1, отрезок 2.
Правила формы (г): агрегат 4.3, генератор 4.8, литерал null 4.2, проверка принадлежности 4.4, строковый литерал 4.2, форма управления с промежуточной проверкой 4.4, числовой литерал
Области действия описаний
Для каждой формы описания правила языка определяют конкретную часть текста программы, называемую областью действия описания или областью действия описанного понятия. Более того, если описание сопоставляет некоторое обозначение с описанным понятием, то эта часть текста также называется областью действия этого обозначения (либо идентификатора, либо символьного литерала, либо знака операции, либо обозначения базовой операции). В области действия понятия, и только в ней, есть места, в которых будет правильным использовать сопоставленное обозначение для ссылки на описанное понятие. Эти места определены правилами видимости и совмещения.
Область действия описания, находящегося непосредственно в зоне описания, распространяется от начала описания до конца зоны описания; этот раздел области действия описания называется непосредственной областью действия. Более того, для любого из описаний, перечисленных ниже, область действия описания распространяется за пределы непосредственной области действия:
а) описание, которое находится непосредственно в видимом разделе описания пакета;
б) описание входа;
в) описание компоненты;
г) спецификация дискриминанта;
д) спецификация параметра;
е) описание параметра настройки.
В каждом из этих случаев данное описание находится непосредственно в некотором охватывающем описании, а область действия данного описания распространяется до конца области действия охватывающего описания.
При отсутствии описания подпрограммы спецификация подпрограммы, заданная в теле подпрограммы или в следе тела, действует как описание, и в этом случае применимо правилоД).
Примечание. Приведенные правила, определяющие область действия, применяются для всех форм описаний, определенных в разд. 3.1; они применяются, в частности, и к неявным описаниям. Правило а) применяется к описанию пакета и тем самым неприменимо к спецификации пакета в описании настройки. Для вложенных описаний правила от а) до е) применяются на каждом уровне. Например, если задачный модуль описан в видимом разделе пакета, то область действия входа задачного модуля распространяется до конца области действия этого задачного модуля, т. е. до конца области действия охватывающего пакета. Область действия спецификатора использования определена в разд.
Ссылки: видимость 8.3, видимый раздел 7.2, задача 9, знак операции 6.1, зона описания 8.1, идентификатор 2.3, именуемый тип 3.7, находится непосредственно в 8.1, неявное описание 3.1, описание 3.1, описание входа 9.5, описание задачи 9.1, описание компоненты 3.7, описание настройки 12.1, описание пакета 7.1, описание параметров настройки 12.1, описание переименования 8.5, описание подпрограммы 6.1, описание типа 1, основная операция 3, распространяется 8.1, спецификатор использования 8.4, символьный литерал 2.5, след тела 10.2, совмещение 6.6, 8.7, спецификация дискриминанта 1, спецификация пакета 7.1, спецификация параметра 6.1, тело подпрограммы
Описания переименования
Описание переименования задает другое имя для понятия.
описание-переименования ::= идентификатор : обозначение-типа renames имя-объекта; | идентификатор : exception renames имя-исключения; | package идентификатор renames имя-пакета; | спецификация-подпрограммы renames имя-подпрограммы-или-входа;Предвыполнение описания переименования вычисляет имя, которое следует после зарезервированного слова renames, и таким образом определяет понятие, обозначенное этим именем (переименованное понятие). В любой точке, где описание переименования видимо, идентификатор или знак операции, заданный в этом описании, обозначает переименованное понятие.
Первая форма описания переименования используется для переименования объектов. Переименованное понятие должно быть объектом базового типа обозначения типа. Описание переименования не изменяет свойств переименованного объекта. В частности, описание переименования не оказывает влияния на значение объекта и на то, является ли он константой или нет; аналогично переименования не затрагивают ограничения, накладываемые на объект (любое ограничение, которое следует из обозначения типа, входящего в описание переименования, игнорируется). Описание переименования правильно только в том случае, если точно один объект имеет этот тип и может быть обозначен этим именем объекта.
Существуют следующие ограничения, связанные с переименованием подкомпоненты переменной, которая зависит от дискриминантов. Переименование недопустимо, если подтип переменной, как это определено в соответствующем описании объекта, описании компоненты или указании подтипа компоненты, является неограниченным типом или если переменная — это формальный объект настройки (вида in out). Также если переменная — формальный параметр, то переименование недопустимо, если заданное в спецификации параметра обозначение типа обозначает неограниченный тип, чьи дискриминанты имеют выражения по умолчанию.
Вторая форма описания переименования используется для переименования исключений;третья форма — для переименования пакетов.
Последняя форма описания переименования используется для переименования подпрограмм и входов. Переименованная подпрограмма или вход и спецификация подпрограммы, заданная в описании переименования, должны иметь один и тот же профиль типа параметров и результата (см. 6.6). Описание переименования правильно только в том случае, если точно одна видимая подпрограмма или вход удовлетворяют упомянутым выше требованиям и могут быть обозначены конкретным именем подпрограммы или входа. Кроме того, виды параметров должны совпадать с видами соответствующих по позиции формальных параметров.
Переименование не оказывает влияния на подтипы параметров и результата (если он есть) переименованной подпрограммы или входа. Эти подтипы заданы в первоначальном описании подпрограммы, конкретизации настройки или описании входа (но не в описании переименования), а также для вызовов, которые используют новое имя. С другой стороны, описание переименования может вводить имена параметров и выражения по умолчанию, которые отличаются от заданных для переименованной подпрограммы; именованные сопоставления в вызовах с новым именем подпрограммы должны использовать новое имя параметра; вызовы со старым именем подпрограммы должны использовать старые имена параметров.
Процедура может быть переименована только как процедура. Функция либо операция могут быть переименованы как функция либо как операция; при переименовании функции или операции операцией спецификация подпрограммы, заданная в описании переименования, подчиняется правилам разд. 6.7 для описаний операции. Литералы перечисления могут быть переименованы как функции; аналогично'атрибуты, определенные как функции (такие, как SUCC или PRED), могут быть переименованы как функции. Вход может быть переименован только как процедура; новое имя допускается только в контексте, допускающем имя процедуры. Вход из семейства может быть переименован, но семейство входов не может быть переименовано целиком. /
function ROUGE return COLOR renames
Примечание
declare L : PERSON renames LEFTMOST_PERSON; -- см. 1 begin L.AGE := L.AGE + 1; end;FULL : exception renames TABLE_MANAGER.TABLE_FULL; -- CM. 7.5 package TM renames TABLE.MANAGER;function REAL_PLUS(LEFT, RIGHT : REAL ) return REAL renames "+"; function INT_PLUS (LEFT, RIGHT : INTEGER) return INTEGER renames "+"; function ROUGE return COLOR renames RED; —- CM. 1 function ROT return COLOR renames RED; function ROSSO return COLOR renames ROUGE:function NEXT(X : COLOR) return COLOR renames COLOR'SUCC; - CM. 5 Примеры описания переименования с новыми именами параметров:
function "*" (X.Y : VECTOR) return REAL renames DOT_PRODUCT; —- CM. 6.1 Пример описания переименования с новым выражением по умолчанию:
function MINIMUMtL : LINK := HEAD) return CELL renames MIN-.CELL; — CM. 6.1
Примечание. Переименование может быть использовано для разрешения конфликта имен и введения сокращений. Переименование другим идентификатором или символом операции не скрывает старое имя; новое и старое имена (символ операции) не обязательно видимы в одних и тех же точках. Атрибуты РОЗ и VAL не могут быть переименованы, так как не могут быть написаны соответствующие спецификации; это положение справедливо для предопределенных мультипликативных операций с результатом универсального-фиксированного типа.
Вызовы переименованного входа с новым именем являются операторами вызова процедуры и недопустимы в местах, где синтаксис требует оператора вызова входа в условном и временном вызовах входа; аналогично атрибут COUNT нельзя применить к новому имени.
Объект задачного типа, описанный посредством описания объекта, может быть переименован как объект. Однако одиночная задача не может быть переименована, так как соответствующий задачный тип является анонимным. По тем же причинам не может быть переименован объект анонимного индексируемого типа. Не существует синтаксической формы для переименования настраиваемого модуля.
Для достижения эффекта переименования типа (включая задачный тип) может быть использован подтип, например:
subtype MODE is TEXT_IO.FILE_MODE ; \
Ссылки: атрибут 4, базовый тип 3.3, вид 6.1, видимость 8.3, временный вызов входа 3, вход 9.5, вызов входа 9.5, вызов подпрограммы 6.4, выражение по умолчанию 6.1, вычисление имени 4.1, дискриминант 1, допустимый 1.6, зависеть от дискриминанта 1, задачный объект 9.2, зарезервированное слово 2.9, знак операции 6.1, идентификатор 2.3, имя 4.1, исключение 11, константа 1, литерал перечисления 1, обозначение типа 3^3.2, объект 3.2, ограничение 3.3, ограниченный подтип 3.3, оператор вызова входа 9.5, оператор вызова процедуры 6.4, операция 6.7, описание 3.1, описание входа 9.5, описание объекта 3.2, описание операции 6.7, описание подпрограммы 6.1, пакет 7, параметр 6.2, переменная 1, подкомпонента 3.3, подпрограмма 6, подтип 2, правильно 1.6, предвыполнение 3.1, процедура 6.1, семейство входов 9.5, спецификация параметра 6.1, спецификация подпрограммы 6.1, тип 3.3, условный вызов входа 2, формальный параметр 6.1, функция
Стандартный пакет
Предопределенные типы (например, BOOLEAN, CHARACTER и INTEGER) описаны в предопределенном пакете, называемом STANDARD; этот пакет включает также описания предопределенных для них операций, ракет STANDARD описан в приложении С. Спецификация пакета STANDARD, за исключением предопределенных числовых типов, должна быть одинаковой для всех реализации языка.
Пакет STANDARD образует зону описания, которая охватывает каждый библиотечный модуль и, следовательно, главную программу; предполагается, что описание каждого библиотечного модуля находится непосредственно в этом пакете. Предполагается также, что неявные описания библиотечных модулей упорядочены таким образом, что область действия данного библиотечного модуля включает в себя любой компилируемый модуль, который упоминает в спецификаторе совместности этот библиотечный модуль. Однако видимыми в данном компилируемом модуле являются библиотечные модули, упомянутые в каких-либо спецификаторах совместности при данном модуле, а если он является вторичным модулем некоторого библиотечного модуля, то и этот модуль является видимым для него.
Примечание. Если все вложенные операторы блока программы поименованы, то имя каждого программного модуля, вложенного в блок, всегда может быть записано как расширенное имя, начинающееся с идентификатора STANDARD (в случае когда этот пакет не является скрытым).
Если тип описан в видимом разделе библиотечного пакета, то из правил видимости следует, что базовая операция (например, присваивание) над этим типом непосредственно видима в точке, где сам тип невидим (либо по имени, либо непосредственно). Однако эта операция может быть применена только к тем операндам, которые являются видимыми, и описание этих операндов требует видимости либо типа, либо одного из его подтипов.
Ссылки: библиотечный модуль 10.1, видимость 8.3, вторичный модуль 10.1, главная программа 10.1, должно 1.6, зона описания 8.1, идентификатор 2.3, имя 4.1, имя блока 5.6, находится непосредственно в 8.1, неявное описание 3.1, оператор блока 5.6, оператор цикла 8.5, операция 6.7, описание 3.1, пакет 7, подтип 3.3, применяемый спецификатор совместности 1, программный модуль 6, расширенное имя 3, скрытие 8.3, спецификатор совместности 1, тип
Видимость
Правила видимости, а в случае совмещенных операций и правила совмещения, трактуют вхождение идентификатора в данной точке текста программы. Под идентификатором в данной главе подразумевают любой идентификатор, кроме зарезервированных слов, обозначений атрибутов, идентификаторов прагм и аргументов прагм. Под точкой текста программы в этой главе понимают место вхождения лексемы (например, идентификатора), а под совмещенными описаниями — описания подпрограмм, литералов перечисления, одиночных входов.
Для каждого идентификатора и в каждой точке текста программы правила видимости определяют набор описаний (с этим идентификатором), т. е. варианты трактовки идентификатора. Говорят, что описание видимо в данной точке текста, когда, согласно правилам видимости, оно определяет возможные трактовки его вхождения. Возникают два случая:
•Правила видимости определяют не более одной трактовки идентификатора. В таком случае правил видимости достаточно для выявления описания, определяющего трактовку вхождения идентификатора, или при отсутствии такого описания для выявления того, что это вхождение в данной точке незаконно, не является правильным.
• Правила видимости определяют более чем одну трактовку. В таком случае вхождение идентификатора является правильным в данной точке, если и только если точно одно видимое описание выбирается правилами совмещения в соответствии с данным контекстом (см. разд. 6.6 для правил совмещения и разд. 8.7 для контекста, используемого при разрешении совмещения).
Описание видимо только в определенной части своей области действия; эта часть начинается в конце описания, а в спецификации пакета эта часть начинается с зарезервированного слова is, следующего за идентификатором пакета. (Это правило применяется, в частности, для неявных описаний.)
Видимость может быть прямой или видимостью по имени. Описание видимо по имени в точках программы для:
а) описания, находящегося в видимом разделе описания пакета — на месте постфикса после точки в расширенном имени, префикс которого обозначает пакет;
б) описания входа конкретного задачного типа — на месте постфикса после точки в именованной компоненте, префикс которой соответствует задачному типу;
в) описания компоненты конкретного описания именуемого типа — на месте постфикса после точки в именованной компоненте, префикс которой соответствует этому типу, а также на месте простого имени компоненты (перед составным ограничителем =>) в именованном сопоставлении компонент агрегата этого типа;
г) спецификации дискриминанта конкретного описания типа — в местах, предназначенных для описания компоненты и простого имени дискриминанта (перед составным ограничителем =>) в именованном сопоставлении дискриминанта в ограничении дискриминанта для этого типа;
д) спецификации параметра данной спецификации подпрограммы или описания входа — на месте формального параметра (перед составным ограничителем =>) в именованном сопоставлении параметра соответствующей подпрограммы или вызова входа;
е) описания параметра настройки данного настраиваемого модуля — на месте формального параметра настройки (перед составным ограничителем =>) в именованном сопоставлении соответствующей конкретизации настройки.
Наконец, в зоне описания, связанной с конструкцией, не являющейся описанием именуемого типа, любое описание видимо по имени на месте постфикса после точки в расширенном имени, префикс которого обозначает эту конструкцию.
Там, где нет видимости по имени, говорят, что описание видимо непосредственно. Описание видимо непосредственно в определенном разделе его непосредственной области действия; этот раздел распространяется до конца непосредственной области действия описания, за исключением тех мест, где это описание скрыто, как поясняется ниже. Кроме того, описание, находящееся непосредственно в видимом разделе пакета, может быть сделано непосредственно видимым с помощью спецификатора использования по правилам, описанным в разд. 8.4 (см. также разд. 8.6 о видимости библиотечных модулей).
Описание скрыто во внутренней зоне описания, если она содержит омоним этого описания; внешнее описание является тогда скрытым в непосредственной области действия этого внутреннего омонима. Каждое из двух описаний является омонимом другого, если оба описания имеют один и тот же идентификатор и не более чем для одного из них допустимо совмещение. Если совмещение допустимо для обоих описаний, то каждое из двух является омонимом другого в случае, если они имеют одинаковый идентификатор, символ операции или символьный литерал, а также одинаковый профиль типа параметров и результата (см. 6.6).
В спецификации подпрограммы скрыто каждое описание с таким же обозначением, как у подпрограммы; данное положение справедливо для конкретизации настройки, которая описывает подпрограмму, и в описании входа или в разделе формальных параметров оператора принятия. В этих случаях описание не является видимым ни по имени, ни непосредственно.
Два описания, которые находятся непосредственно в одной и той же зоне описания, не должны быть омонимами, за исключением тех случаев, когда выполнены одно или оба следующих требования: а) точно одно из них является неявным описанием предопределенной операции; б) точно одно из них является неявным описанием производной подпрограммы. В таких случаях предопределенная операция всегда скрыта другим омонимом; производная подпрограмма скрывает предопределенную операцию, но скрыта сама любым другим омонимом.
Там, где скрытие осуществляется таким образом, неявное описание скрыто во всей области действия другого описания (независимо от того, какое описание стоит первым); неявное описание не видимо ни по имени, ни непосредственно.
Всегда, когда описание с определенным идентификатором видимо в данной точке, говорят, что идентификатор и описанное понятие (если оно есть) видимы в этой точке. Непосредственная видимость и видимость по имени для символьных литералов и символов операций определяются аналогично. Операция, обозначенная знаком, непосредственно видима тогда и только тогда, когда описание соответствующей операции непосредственно видимо. Наконец, обозначения, связанные с базовой операцией, непосредственно видимы во всей области действия этой операции.
Пример:
procedure P is А, В : BOOLEAN; procedure Q is С : BOOLEAN; В : BOOLEAN; -— внутренний омоним В begin ... B := А; -- означает.а.в := Р.А; С := Р.В; -— означает Q.C := Р.В; end; begin А := B; -—означает Р.А := Р.В; end;Примечание о видимости библиотечных модулей. Видимость библиотечных модулей определена спецификаторами совместности (см. 1) и тем фактом, что библиотечные модули неявно описаны в пакете STANDARD (см. 8.6).
Примечание об омонимах. Один и тот же идентификатор может находиться в различных описаниях и, таким образом, соответствовать различным понятиям, даже если области действия описаний перекрываются. Перекрытие областей действия описаний с одним и тем же идентификатором может получиться из-за совмещения подпрограмм и литералов перечисления. Такое перекрытие может произойти для понятий, описанных в видимых разделах пакета, а также входов, компонент записей и параметров, где имеется перекрытие областей действия охватывающих описаний пакета, описаний задачи, описаний именуемого типа, описаний подпрограмм, описаний переименований и описаний настройки. Наконец, перекрытие областей действия может быть результатом вложенности.
Примечание к непосредственной области действия, скрытию и видимости. Правила, определяющие непосредственную область действия, скрытия и видимости, предусматривают, что ссылка на идентификатор в его собственном описании является неправильной (исключая случаи пакетов и настраиваемых пакетов). Идентификатор скрывает внешние омонимы в собственной непосредственной области действия, т. е. от начала описаний; с другой стороны, идентификатор является видимым только после конца описания. По этой причине (кроме последнего) все следующие описания являются неправильными.
K : INTEGER := K * K; -- неправильно T : T; -- неправильно procedure Р(х : P); -- неправильно procedure Q(X : REAL := Q); -- неправильно даже если существует функция с именем Q procedure R(R : REAL); -- правильное, хотя создает путаницу.Ссылки: агрегат 4.3, аргумент 2.8, базовая операция 3, библиотечный модуль 10.1, видимый раздел 7.2, вызов входа 9.5, вызов подпрограммы 6.4, задачный модуль 9, задачный тип 9.1, зарезервированное слово 2.9, знак операции 6.1, зона описания 8.1, идентификатор 2.3, именованная компонента 3, именуемый тип 3.7, конкретизация настройки 12.3, лексема 2.2, литерал 2.5, настраиваемый модуль 12, настраиваемый пакет 12.1, находится непосредственно в 8.1, непосредственная область действия 8.2, неявное описание 3.1, область действия 8.2, объект 3.2, ограничение дискриминанта 2, оператор принятия 9.5, операция 4.5, описание 3.1, описание входа 9.5, описание компоненты 3.7, описание параметра настройки 12.1, описание подпрограммы 6.1, описание типа 1, пакет 7, параметр 6.2, подпрограмма 6, постфикс
3, прагма 2.8, программный модуль 6, простое имя 4.1, распространяется 8.1, расширенное имя 3, семейство входов 9.5, совмещение 6.6, 8.7, соответствует типу 4.1, сопоставление компонент 4.3, сопоставление параметров 6.4, сопоставление параметров настройки 12.3, составной ограничитель 2.2, спецификатор использования 8.4, спецификация дискриминанта 1, спецификация литерала перечисления 1, спецификация параметра 6.1, спецификация подпрограммы 6.1, тип 3.3, указывать 3.8, формальный параметр 6.1, формальный параметр настройки
- СПЕЦИФИКАТОРЫ ИСПОЛЬЗОВАНИЯ
Спецификатор использования обеспечивает непосредственную видимость описаний, которые находятся в видимых разделах пакетов с именами, упомянутых в спецификаторе использования.
спецификатор-использования ::= use имя-пакета {, имя-пакета};
Для каждого спецификатора использования существует определенная зона текста, называемая областью действия спецификатора использования. Эта зона начинается непосредственно после спецификатора использования. Если спецификатор использования является элементом описания некоторой зоны описания, то область действия спецификатора использования распространяется до конца этой зоны описания. Если спецификатор использования находится в спецификаторе контекста компилируемого модуля, то область действия спецификатора использования распространяется до конца зоны описания, связанной с данным компилируемым модулем.
Чтобы определить, какие описания становятся прямо видимыми в данном месте с помощью спецификатора использования, рассмотрим пакеты, упомянутые в спецификаторах использования, области действия которых охватывают это место. Описанием, которое может быть сделано прямо видимым с помощью спецификатора использования (потенциально видимое описание), является такое описание, которое находится непосредственно в видимом разделе одного из этих пакетов. Потенциально видимое описание становится фактически прямо видимым, за исключением двух случаев:
• Потенциально видимое описание не становится прямо видимым, если рассматриваемое место программы находится непосредственно в области действия описания омонима.
• Потенциально видимые описания с-одинаковыми идентификаторами не становятся прямо видимыми, если только каждое из них не является спецификацией литерала перечисления или описанием подпрограммы (представляющим собой описание подпрограммы, описание переименования, конкретизацию настройки или неявное описание).
Предвыполнение спецификатора использования не имеет другого эффекта. /
Примечание. Приведенные выше правила гарантируют, что описание, которое стало прямо видимым с помощью спецификатора использования, не может скрывать другое прямо видимое описание. Эти правила сформулированы в терминах набора пакетов, упомянутых в спецификаторах использования.
Следовательно, приведенные ниже строчки текста дают один и тот же эффект (в предположении существования единственного пакета Р).
use Р;
use Р; use Р, Р;
Пример противоречия имен в двух пакетах:
procedure R is package TRAFFIC is type COLOR is (RED, AMBER, GREEN); ... end TRAFFIC; package WATER_COLORS is type COLOR is (WHITE, RED, YELLOW, GREEN, BLUE, BROWN, BLACK); ... end WATER_COLORS; use TRAFFIC; -- COLOR, RED, AMBER, и GREEN непосредственно видимы use WATER_COLORS; -- Два омонима GREEN непосредственно видимы, -- butCOLOR не является более непосредственно видимым subtype LIGHT is TRAPPIC.COLOR; -- подтип использован для разрешения subtype SHADE is WATER_COLORS.COLOR; -- противоречия, связанного с именем типа. COLOR SIGNAL : LIGHT; PAINT : SHADE; begin SIGNAL := GREEN; -— из пакета TRAFFIC PAINT := GREEN; -— из пакета WATER-COLORS end R;Пример идентификации имени со спецификатором использования:
package D is Т, U, V : BOOLEAN; end D;procedure P is package E is B, W, V : INTEGER; end E; procedure Q is Т, Х : REAL; use D, E; begin -— имя Т означает Q.Т, not D.T -— имя U ознaчaeT D.U -— имя В означает Е.В -— имя W oзнaчaeT E.W -— имя Х означает Q.Х -— имя неправильно: должно быть использовано D.V или ... end Q; begin ... end P;Ссылки: видимый раздел 7.2, зона описания 8.1, идентификатор 2.3, имя 4.1, компилируемый модуль 10.1, находиться непосредственно в 8.1, непосредственная видимость 8.3, непосредственная область действия 8.2, область действия 8.2, омоним 8.3, описание 3.1, описание подпрограммы 6.1, пакет 7, Предвыполнение 3.1, 3.9, Предвыполнение не имеет другого эффекта 3.1, распространение 8.1, скрытие 8.3, спецификатор контекста 10.1, спецификация литерала перечисления 1, элемент описания
Зона описания
Зона описания является частью текста программы. Единичная зона описания — это:
• Описание подпрограммы, описание пакета, описание задачи или описание настройки с соответствующим телом (если оно есть). Если это тело — след тела, то зона описания включает также соответствующий субмодуль. Если программный модуль содержит субмодули, то они также включаются в зону описания.
• Описание входа с соответствующими операторами принятия.
• Описание именуемого типа с соответствующими описанием личного типа или неполным описанием типа (если они есть) и спецификатором представления записи (если он есть).
• Описание переименования, содержащее раздел формальных параметров, или описание параметров настройки, включающее либо раздел формальных параметров, либо раздел дискриминантов.
•Оператор блока или оператор цикла.
В каждом из перечисленных выше случаев говорят, что зона описания связана с соответствующим описанием или оператором. Описание находится непосредственно в зоне описания, если она является самой вложенной охватывающей данное описание без учета зоны описания (если она есть), связанной с самим описанием.
Описание, которое находится непосредственно в зоне описания, является локальным в этой зоне. Говорят, что описания во внешних (охватывающих) зонах являются глобальным по отношению к внутренней (охватываемой) зоне описания. Локальные понятия — это те, которые описаны непосредственно локальными описаниями; глобальные понятия — это те, которые описаны посредством глобальных описаний.
Некоторые из упомянутых выше форм зон описания включают несколько разъединенных разделов (например, между описанием пакета и его телом могут быть помещены другие элементы описания). Тем не менее каждая зона описания рассматривается как непрерывная часть текста программы (логически). Следовательно, если какое-либо правило определяет часть текста, расположенного от некоторой выделенной точки зоны описания до конца зоны, то эта часть является соответствующим подмножеством данной зоны описания (в нее не включаются, например, промежуточные элементы описания, расположенные между двумя разделами пакета).
Примечание. Как определено в разд. 3.1, в термин описание включаются основные описания, неявные описания и описания, являющиеся разделом основных описаний, например спецификации дискриминантов и параметров. Из определения зоны описания следует, что спецификация дискриминанта находится непосредственно в зоне, связанной с охватывающим описанием именуемого типа. Аналогично спецификация параметра находится непосредственно в зоне, связанной с телом охватывающей подпрограммы или с оператором принятия.
Пакет STANDARD образует зону описания, которая охватывает все библиотечные модули;предполагается, что неявное описание каждого библиотечного модуля находится непосредственно в этом пакете (см. разд. 8.6 и 1).
Зоны описания могут быть вложены в другие зоны описания. Например, подпрограммы, пакеты, задачные модули, настраиваемые модули и операторы блока могут быть вложены друг в друга и содержать описания именуемого типа, оператор цикла, а также операторы принятия.
Ссылки: библиотечный модуль 10.1, задачный модуль 9, именуемый тип 3.7, настраивав-1 мое тело 12.2, неполное oni-ср.ние типа 1, неявное описание 3.1, оператор блока 5.6, оператор принятия 9.5, оператор цикла 5.5, описание 3.1, описание входа 9.5, описание задачи 9.1, описание личного типа 7.4, описание настройки 12.1, описание пакета 7.1, описание параметров настройки 12.1, описание переименования 8.5, описание подпрограммы 6.1, основное описание 3.1, пакет 7, раздел дискриминантов 1, раздел формальных параметров 6.1, след тела 10.2, спецификатор представления записи 13.4, спецификация дискриминанта 1, спецификация параметра 6.1, стандартный пакет 8.6, субмодуль 10.2, тело задачи 9.1, тело пакета 7.1, тело подпрограммы