Пратт Т. Языки программирования. Разработка и реализация

Подождите немного. Документ загружается.

44 Глава 1. Проблемы разработки языка

бинирования их определенным образом), чтобы получить требуемый ответ? Язы

ки, в которых акцентирован именно этот взгляд на вычисления, называются ап

пликативными, или функциональными.

Рис. 1.1. Вычислительные модели языков программирования

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

чальные данные и путем воздействия на их представление в памяти (как при про

хождении света через линзу) производит желаемый ответ. Разработка программ

сводится к созданию из уже имеющихся простых функций более сложных функ

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

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

тривать последовательные состояния машины, в данной модели мы концентрируем

наше внимание на последовательных преобразованиях начальных данных с помо

щью функций. Как только у нас есть конечный ответ (последовательность функ

ций), его можно применить к начальным данным и получить результат. Синтак

сис такого языка, как правило, выглядит следующим образом:

ôóíêöèÿ

(…ôóíêöèÿ

(ôóíêöèÿ

(äàííûå))…)

Из описанных в данной книге языков функциональную модель поддерживают

ML и LISP.

Языки, основанные на системе правил. Языки, основанные на системе правил,

осуществляют проверку наличия необходимого разрешающего условия и в случае

его обнаружения выполняют соответствующее действие. Наиболее распространен

ный язык, основанный на системе правил, — Prolog. Он называется также языком

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

к классу выражений логики предикатов (более подробно данная тема будет рас

смотрена в разделе 8.4.2). На рис. 1.1, в языки, основанные на системе правил, схе

матически представлены с помощью набора фильтров, которые нужно применить

к данным, находящимся в памяти. Выполнение программы на подобном языке

похоже на выполнение программы, написанной на императивном языке, за исклю

чением того, что операторы выполняются не в той последовательности, в которой

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

нения. Синтаксис таких языков выглядит следующим образом:

ðàçðåøàþùåå óñëîâèå1 → äåéñòâèå1

ðàçðåøàþùåå óñëîâèå2 → äåéñòâèå2

…

ðàçðåøàþùåå óñëîâèån → äåéñòâèån

(Иногда правила записываются в виде äåéñòâèå if ðàçðåøàþùåå óñëîâèå, в кото

ром выполняемое действие записывается слева.)

Хотя Prolog — наиболее известный из языков такого класса, существует также

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

приложение таблиц решений является формой языка, основанного на системе пра

вил. В данном случае разрешающие условия для данных обусловливаются нали

чием или отсутствием допустимых значений в записях данных. Программирование

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

соответствующих действий в случае выполнения этого условия (отсюда и назва

ние). Методы синтаксического разбора НФБ (описываемые в главе 3) и средства

синтаксического разбора типа YACC (Yet Another Compiler Compiler) относятся к

технологиям, основанным на системе правил, в которых формальный синтаксис

программы рассматривается в качестве разрешающего условия.

Объектно(ориентированное программирование. Как будет показано в главе 7,

значимость объектноориентированной модели постоянно возрастает. В этой мо

дели строятся сложные объекты данных, а затем для операций над этими данными

описывается ограниченный набор функций. Сложные объекты создаются как рас

ширения более простых объектов и наследуют их свойства. Как мы покажем, на

самом деле эта модель является попыткой объединить лучшие свойства других

моделей. Благодаря возможности строить конкретные объекты данных объектно

ориентированная программа приобретает эффективность императивного языка.

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

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

Универсальность вычислительной модели

При описании конкретных вычислительных моделей мы специально старались

использовать термин «поддерживать», а не «реализовывать». То, как программист

1.3. Роль языков программирования

46 Глава 1. Проблемы разработки языка

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

операторноориентированное программирование, управляющее внутренним ма

шинным состоянием компьютера; но, в принципе, можно написать программы,

которые будут выполняться последовательно и выполнять те же функции, на язы

ках LISP или Prolog. Также на языке C относительно легко написать программу,

состоящую только из вызовов функций и поэтому похожую на аппликативную.

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

возможности и свойства языков.

Исторически сложилось так, что императивные языки составили первый ши

роко используемый класс языков и в настоящее время остаются доминирующими

в программировании. Одним из наиболее интересных результатов исследований 70–

80х гг. оказался тот факт, что аппликативная методика обеспечивает эффективные

способы верификации программ и доказательства их корректности. Это видно из

блоксхем, представленных на рис. 1.2. На рис. 1.2, а изображена блоксхема, типич

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

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

обычно называют программамиспагетти (с большим числом нерациональных пе

редач управления назад и вперед), поскольку маршруты управления напоминают

тарелку со спагетти. В таких программах часто бывает трудно понять, каково состо

яние программы в каждый момент времени в процессе ее выполнения.

Ïðîãðàììà-ñïàãåòòè

Ñòðóêòóðèðîâàííàÿ ïðîãðàììà

Рис. 1.2. Аппликативные методы в императивных языках

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

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

четырех прямоугольников на этой схеме имеет одну входную и одну выходную стрел

ки. Эту программу можно рассматривать как композицию четырех функций, и по

ведение программы можно определить как функцию, которая получает данное со

стояние на входе выделенного пунктиром прямоугольника и преобразует его в ре

зультирующее состояние на выходе из него. Однако это всегонавсего форма аппли

кативной модели, описанной ранее. В дальнейшем, при описании простых программ

в разделе 8.3.3, мы обсудим этот момент подробнее. В основе большинства исследо

ваний по проверке программ с использованием формальных доказательств правиль

ности программы лежит применение аппликативных методов к императивным про

граммам. Как будет показано в главе 4, некоторые из предикатных и алгебраических

методов основаны на аппликативной модели. Также мы увидим, что объектноори

ентированное программирование является альтернативной возможностью приме

нения аппликативной модели к императивным программам.

1.3.3. Стандартизация языка

Что описывает язык программирования? Рассмотрим следующий код, написан

ный на языке C:

int i; i=(1&&2)+3;

Действительно ли это правильный синтаксис C? Каково значение i? Как бы вы

ответили на эти вопросы?

Как правило, чтобы ответить на подобные вопросы,

применяют три подхода:

1. Прочитать в справочном руководстве по языку определение соответствую

щих операций и выяснить, что означает написанный код.

2. Написать программу и посмотреть, что она вычислит.

3. Прочитать определение операций в описании стандарта языка.

Второй способ, наверное, является самым распространенным, поскольку сесть

и написать программу из двухтрех строчек и посмотреть, что получится, не со

ставляет труда. Вообщето концепция языка программирования тесно связана с

конкретной его реализацией, используемой на локальном компьютере. Если вы

предпочитаете более научный подход, можно обратиться к справочному руковод

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

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

применяется сравнительно редко.

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

рования связана с его конкретной реализацией. Но является ли эта реализация пра

вильной? А что, если понадобится перенести программу, написанную на языке C и

состоящую из 50 000 строчек, на другой компьютер, где установлен компилятор C

от другого поставщика? Попрежнему ли программа будет правильно скомпилиро

вана и при выполнении выдаст тот же результат? Если нет, то почему? Зачастую

идеология языка включает в себя некоторые неочевидные детали, интерпретация

которых может различаться в различных реализациях, что порождает несколько раз

ное поведение программы при ее выполнении на различных компьютерах.

Однако некоторые поставщики программного обеспечения могут решить, что

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

Заметим (для любопытных), что ответы на первый и второй вопросы соответственно «да» и «4».

1.3. Роль языков программирования

48 Глава 1. Проблемы разработки языка

Допустимо ли такое? Например, если добавить в язык C новый способ объявле

ния динамических массивов, можно ли язык с подобным расширением попрежне

му называть языком C? Если это случится, то программу, использующую эту но

вую возможность и компилирующуюся на локальном компиляторе, в котором

подобная возможность реализована, невозможно будет скомпилировать в другой

системе, использующей другой компилятор языка.

Для разрешения подобных проблем многие языки имеют стандартные опреде

ления. Все реализации должны придерживаться этого стандарта. Стандарты обычно

бывают двух видов.

1. Частный стандарт. Сюда входят определения, сделанные той компанией,

которая разработала язык и имеет на него авторские права. В большинстве

случаев для популярных и широко используемых языков такие стандарты

не работают, поскольку в этих случаях часто появляются новые реализации,

усовершенствованные и несовместимые.

2. Согласительный стандарт. К нему относятся созданные специальными

организациями документы, основанные на соглашении всех заинтересо

ванных участников. Согласительный стандарт, или просто стандарт, явля

ется основным способом обеспечения единообразия различных реализаций

языка.

В каждой стране, как правило, есть одна или несколько организаций, наде

ленных правом разработки стандартов. В Соединенных Штатах это Американ

ский национальный институт стандартов (ANSI — American National Standards

Institute). Стандарты языков программирования могут разрабатываться коми

тетом X3 Ассоциации производителей делового компьютерного оборудования

(CBEMA — Computer Business Equipment Manufactures Association), а также

Институтом инженеров по электротехнике и электронике (IEEE — Institute of

Electrical and Electronic Engineers). В Великобритании такими полномочиями

наделен Британский институт стандартов (BSI — British Standards Institute).

Международные стандарты создаются Организацией международных стандар

тов (ISO — International Standards Organization), штабквартира которой нахо

дится в Женеве (Швейцария).

В Соединенных Штатах следование стандартам — дело добровольное. Нацио

нальный институт стандартов и технологий (NIST — National Institute of Standards

and Technology), являющийся правительственным органом, создает федеральные

стандарты. Выполнение этих стандартов является обязательным только для по

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

нам. Частные же компании могут не следовать этим стандартам. Однако федераль

ные стандарты всегда принимаются в качестве общих, а NIST, ANSI, IEEE и ISO

обычно разрабатывают стандарты совместно.

Процесс разработки стандартов во всех подобных организациях одинаков. В не

который момент специальная группа решает, что язык необходимо стандартизо

вать. Затем совет по стандартам нанимает группу добровольцев для разработки

стандарта. Когда эта рабочая группа вырабатывает свой вариант стандарта, он пе

реходит на голосование в группу заинтересованных лиц. Расхождения, выявлен

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

Хотя теоретически все выглядит хорошо, на самом деле создание стандартов

является отчасти технической, а отчасти и политической проблемой. Например,

поставщики компиляторов имеют определенный финансовый интерес в создании

определенных стандартов. Естественно, они хотят, чтобы стандарт был как можно

ближе к их компилятору, чтобы не пришлось вносить изменения в свою реали

зацию. Такие изменения не только дорого стоят сами по себе, они приводят еще

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

ром, перестают отвечать стандарту. Это, разумеется, создает неудобства потре

бителям.

Поэтому, как и отмечалось выше, создание стандартов — процесс, основанный

на компромиссах. Не каждый извлекает из него выгоду, но все же имеется надеж

да, что получившийся в результате язык будет приемлемым для всех. Рассмотрим

следующий простой пример. В процессе обсуждения стандарта FORTRAN 77 все

стороны пришли к соглашению, что поскольку большинство реализаций FORTRAN

уже имели строки и подстроки, желательно стандартизовать такую возможность.

Однако существовало несколько реализаций подстрок. Для пояснения рассмот

рим строку M = "abcdefg". Согласно одной реализации, подстрока "bcde" обозна

чалась M[2:5], то есть строка, состоящая из символов строки M со второго по пятый.

В другой реализации та же подстрока обозначалась M[2:4], то есть строка, начина

ющаяся с позиции 2 и имеющая 4 символа. Если же считать символы справа нале

во, ту же подстроку можно было записать и как M[3:6]. Поскольку невозможно было

достигнуть никакого соглашения по этому вопросу, было решено просто оставить

его за рамками стандарта. Хотя этот стандарт не отвечает большинству высказан

ных в данной главе требований, принятое решение оказалось вполне подходящим.

По этой причине стандарты являются полезными документами, но на определе

ние языка могут оказать влияние некоторые сиюминутные политические сообра

жения.

Чтобы использовать стандарт эффективно, следует рассмотреть три аспекта

стандартизации.

1. Своевременность. Когда нужно стандартизовать язык?

2. Соответствие. Как определить, что программа соответствует стандарту, а ком

пилятор компилирует согласно стандарту?

3. Устаревание. Что обусловливает устаревание стандарта и как его следует

модифицировать?

Рассмотрим все эти вопросы по очереди.

Своевременность. Одним из важных вопросов является определение момента,

когда следует стандартизовать язык. Язык FORTRAN впервые был стандартизо

ван в 1966 г., когда уже существовало несколько несовместимых его версий. Это

привело к некоторым проблемам, поскольку каждая реализация отличалась от

других. Другой крайностью является язык Ada, который впервые был стандарти

зован в 1983 г., еще до того, как возникла первая реализация. Когда создавался

этот стандарт, еще никто не мог сказать, будет ли вообще этот язык работать. Пер

вые эффективные компиляторы Ada появились только в 1987 г., а некоторые недо

статки этого языка были обнаружены только при создании этих первых реализа

ций. Таким образом, следует создавать стандарт языка не слишком рано, чтобы

1.3. Роль языков программирования

50 Глава 1. Проблемы разработки языка

накопилось достаточно опыта в его применении, но и не слишком поздно, чтобы

не поощрять создание несовместимых реализаций.

Из языков, описанных в данной книге, FORTRAN был стандартизован слиш

ком поздно, когда было уже много несовместимых реализаций, а Ada, наоборот, —

слишком рано, когда еще не было ни одной. Вовремя появились стандарты языков

C и Pascal, когда они уже начали распространяться, но еще не было большого ко

личества несовместимых версий.

Соответствие. Если существует стандарт языка, то, естественно, возникает во

прос о соответствии этому стандарту. Программа считается соответствующей

стандарту, если она использует только те возможности, которые определены дан

ным стандартом. Компилятор является соответствующим стандарту, когда пос

ле компиляции соответствующей стандарту программы при ее выполнении полу

чается правильный результат.

Следует отметить, что здесь ничего не говорится о расширениях стандарта.

Если в компилятор добавлены дополнительные возможности, то любая про

грамма, использующая эти возможности, не является соответствующей стандар

ту и стандарт ничего не говорит о том, какими должны быть результаты выпол

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

стандарту программам. Вследствие этого большинство компиляторов всегда име

ют возможности, которые не описаны стандартом. Поэтому следует проявлять

осторожность при использовании локальной реализации как окончательной

инстанции при выяснении смысла какойлибо языковой конструкции. (В каче

стве примера можно рассмотреть программу anomaly на языке Pascal, приведен

ную в листинге 9.1.)

Устаревание стандартов. Накопленные знания и опыт программирования под

сказывают, что развитие новых компьютерных архитектур требует включения в

языки новых возможностей. Спустя несколько лет после утверждения стандарта

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

FORTRAN 66, поскольку в нем не предусмотрены многие возможности современ

ных языков, такие как типы, вложенные управляющие структуры, инкапсуляция,

блочная структура и многое другое из арсенала современных языков программи

рования.

В связи с этим процесс стандартизации стал предусматривать возможность об

новления. Каждый стандарт должен пересматриваться раз в пять лет и либо об

новляться, либо совсем отменяться. Правда, всегда находится какаялибо причи

на для нарушения пятилетнего срока, но тем не менее такой процесс по большей

части достаточно эффективен. Первый стандарт языка FORTRAN был принят в

1966 г., затем он был пересмотрен в 1978 г. (хотя срок завершения разработки стан

дарта в 1977 г. и был перенесен на несколько месяцев, язык все же называется

FORTRAN 77), а затем в 1990 г. стандарт был снова пересмотрен. Язык Ada был

стандартизован в 1983 г., а пересмотрен в 1995 г.

Один из вопросов, связанных с обновлением стандарта, заключается в следую

щем: что делать с уже существующим набором написанных в соответствии со ста

рым стандартом программ? Компании затратили большие средства на создание

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

новую версию языка — весьма дорогостоящее мероприятие. Поэтому в большин

стве стандартов требуется предусматривать обратную совместимость, то есть но

вый стандарт должен включать в себя более старые версии языка.

Однако при этом возникают некоторые проблемы. Например, язык может стать

слишком громоздким, если в нем накапливать все устаревшие конструкции. Более

того, некоторые из таких конструкций могут препятствовать разработке хорошей

программы. Оператор EQUIVALENCE языка FORTRAN может служить примером та

кой устаревшей конструкции. Пусть A вещественное число, а I— целое, тогда по

следовательность операторов

EQUIVALENCE (A,I)

A=A+1

I=I+1

располагает переменные A и I в одной и той же ячейке памяти. Первая процедура

присваивания (с переменной A) обращается к этой ячейке как к содержащей ве

щественное число и добавляет к нему единицу. Вторая процедура присваивания

(с переменной I) обращается к той же ячейке как к содержащей уже целое число и

также добавляет к нему единицу. Поскольку представления целых и веществен

ных чисел в большинстве компьютеров различны, то результат может быть совер

шенно непредсказуемым. Поэтому сохранение этой конструкции языка нежела

тельно.

В связи с вышесказанным недавно сформировались такие понятия, как уста

ревшая и не рекомендуемая возможности. Возможность называется устаревшей,

если она является кандидатом на исключение из языка уже в следующей версии

стандарта. Такое понятие предупреждает пользователей, что пока еще эта возмож

ность доступна, но в ближайшие 5–10 лет она будет изъята из стандарта языка.

Таким образом, пользователи предупреждаются заблаговременно и имеют время

переписать все коды, содержащие эту конструкцию. Не рекомендуемая возмож

ность в очередном стандарте может стать устаревшей. Таким образом, она может

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

предупредительный период составляет 10–20 лет. В новых программах такие воз

можности уже не следует использовать.

Поскольку расширения языка допускаются и в согласующихся со стандартом

компиляторах (до тех пор, пока они правильно компилируют согласующиеся со

стандартом программы), многие компиляторы имеют дополнения, которые с точ

ки зрения поставщика программного обеспечения являются полезными и способ

ствуют распространению программного продукта. Благодаря такому подходу по

являются нововведения и развивается язык. Конечно, в академической среде

большинство программистов не связывают себя никакими стандартами, а разра

батывают свои собственные продукты, в которых языки модифицированы и рас

ширены подходящим для них образом. Это создает плодородную почву для испы

тания новых языковых концепций, а некоторые наиболее удачные идеи попадают

в коммерческие языки и компиляторы.

1.3.4. Интернационализация

В связи с глобализацией торговли и появлением Всемирной паутины WWW про

граммирование становится все более и более глобальной деятельностью, и поэто

1.3. Роль языков программирования

52 Глава 1. Проблемы разработки языка

му важно, чтобы языки программирования могли легко использоваться в разных

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

«изъясняться» на разных языках. Например, для представления различных сим

волов обычно недостаточно 8битного байта, в котором можно закодировать лишь

256 различных символов. При обсуждении подобных вопросов обычно пользуют

ся термином интернационализация (internationalization)

Зачастую на способ хранения и обработки данных влияют местные соглаше

ния. Такие моменты, как коды символов, схема упорядочения, формат даты и

времени и другие местные стандарты влияют на вид входных и выходных дан

ных. Некоторые из соответствующих факторов перечислены в работе Мартина

[79].

Ê Схемы упорядочения. По какой схеме должно происходить упорядочение

символов?

 Сортировка. Позиции нелатинских символов, таких как Å, Ø , β, ö и дру

гих, не имеют единого определения и могут быть разными в разных стра

нах.

 Регистр. Некоторые языки, такие как японский, арабский, иврит и тай

ский, не имеют понятия о верхнем и нижнем регистрах.

 Направленность письма. На многих языках читают слева направо, но

бывает и подругому (например, справа налево или сверху вниз).

Ê Формат даты. Формат даты зависит от страны. Так, в Америке принято пи

сать 11/26/02 (26 ноября 2002 г.), в Англии же наоборот — 26/11/02. Во

Франции и России пишут 26.11.02, а в Италии — 26XI02 и т. д.

Ê Формат времени. Формат времени также зависит от страны. В Америке

пишут 5:40 p. m., а в Японии и России — 17:40, в Германии это же время выг

лядит как 17.40, а во Франции — 17h40.

Ê Часовые пояса. Хотя существует стандартное правило изменения местного

времени на один час на каждые 15° долготы, на самом деле это скорее общий

принцип, нежели реальность. Обычно часовые пояса различаются на целое

количество часов, но некоторые могут различаться на 15 минут или на пол

часа. Сдвиги времени (такие как летнее время в Америке и Европе) во всем

мире осуществляются неодинаково. Произвести пересчет местного времени

во всемирное стандартное время иногда бывает непросто. В южном полуша

рии переход на летнее время осуществляется противоположно тому, как это

происходит в северном полушарии.

Ê Идеографические системы. Письменность некоторых языков основана на

большом количестве иероглифов, а не на алфавите, состоящем из неболь

шого набора символов (например, в японском, китайском и корейском язы

ках). Обычно для представления текста на таких языках требуется 16 бит.

Ê Денежные единицы. Представление денежных единиц также зависит от

страны (используются, например, такие символы, как $, £, ¥).

Иногда используется термин «проблема I18N», поскольку само слово «internationalization» слиш

ком длинное (20 символов), и, кроме того, название I18N позволяет избежать споров о том, как пи

сать слово «internationalization»: через британское «s» или американское «z».

1.4. Среда программирования

Понятие среды программирования, в которой программа создается и тестируется,

наверняка знакомо большинству читателей этой книги. Однако, как правило, сре

да программирования меньше влияет на строение языка программирования, нежели

операционная среда, использующаяся для запуска программ. В первую очередь

среда программирования состоит из набора средств поддержки и активизирующих

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

использовано программистом как вспомогательное средство на одной или несколь

ких стадиях создания программы. Обычно в средства поддержки входят редак

торы, отладчики, верификаторы, генераторы тестовых данных и программы пе

чати.

1.4.1. Влияние на разработку языка

Среда программирования влияет на разработку языка преимущественно в двух

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

и сборку программы из различных компонентов, и на возможности, облегчающие

тестирование и отладку программы.

Раздельная компиляция. При разработке любой большой программы обычно

желательно по отдельности разработать, закодировать и протестировать все ком

поненты программы, созданные отдельными программистами и группами разра

ботчиков, прежде чем собирать ее в единое целое из этих отдельных блоков. При

таком подходе требуется, чтобы структура языка допускала раздельное компили

рование и выполнение подпрограмм и других компонентов программы в отсут

ствие остальных ее частей и их последующее объединение без какихлибо допол

нительных изменений.

Раздельная компиляция может быть затруднена по той причине, что при ком

пиляции отдельной подпрограммы ей может потребоваться следующая информа

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

1. Описание количества, порядка и типа параметров любой вызываемой под

программы позволяет компилятору проверить правильность вызова внеш

ней подпрограммы. Также может потребоваться информация о том языке,

на котором была написана внешняя подпрограмма. Зная это, компилятор

может составить соответствующую вызывающую последовательность ин

струкций для преобразования данных и управляющей информации, необ

ходимой внешней подпрограмме во время выполнения, именно в той фор

ме, которая требуется для данной подпрограммы.

2. Объявление типа данных для любой используемой переменной позволяет

компилятору определить способ представления каждой внешней перемен

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

с использованием соответствующей формула доступа (например, правиль

ный сдвиг внутри общего блока).

3. Определение тех внешних типов данных, которые используются для описа

ния локальных переменных внутри подпрограммы. Это позволит компиля

1.4. Среда программирования