Modula2 vs Oberon, страница 2

Спецификация произвольной нижней границы вряд ли придаетязыку дополнительную выразительную силу. В то же время это является скорее ограниченнымвидом отображения индексов, которое ведет к скрытым вычислениям, несравнимым с удобствомиспользования. Скрытые накладные расходы проступают особенно сильно при проверке границ ипри работе с динамическими массивами.Модули и правила экспорта-импортаЭксперименты с Modula, проводимые на протяжении последних восьми лет, показали, чтолокальные модули используются крайне редко.

С учетом дополнительной сложности, вносимой вкомпилятор для их поддержки, и принимая во внимание дополнительные усложнения правилвидимости, которые должны быть внесены в описание языка, отказ от локальных модулейвыглядит вполне логичным решением.Квалификацию «M.x» импортируемого объекта «x» именем экспортируемого его модуля «M» вModula можно обойти за счет использования оператора FROM M IMPORT x.

От такой возможностив Oberon мы также отказались. Опыт работы с системами программирования, оперирующимибольшим количеством модулей, показал, что явная квалификация каждого использованияобъекта «x» — это наиболее предпочтительное решение. Связанное с этим упрощениекомпилятора носит в данном случае второстепенное значение.Двойственная роль головного (main) модуля в Modula приводит к концептуальной неясности. Содной стороны, головной модуль задает модуль в смысле пакета данных и процедур с замкнутойобластью видимости, а, с другой, он определяет единственную процедуру, называемую основнойпрограммой.

Модуль состоит из двух блоков, которые называются описательной частью (definitionМИР ПК – ДИСК. 2003. № 8. СТУДИЯ ПРОГРАММИРОВАНИЯ3/12ИСКУССТВО ПРОГРАММИРОВАНИЯАВГУСТ 2003part) и исполнительной частью (implementation part). В случае головного модуля описательнаячасть отсутствует.В отличие от такого подхода в языке Oberon модуль является самостоятельным и законченнымстроительным блоком и определяет единицу компиляции. Описательная и исполнительная частислиты воедино: имена, которые должны быть видны в клиентских модулях, т.е. экспортируемыеидентификаторы, помечаются специальными знаками: они обычно предшествуют описаниям техобъектов, которые не экспортируются. При компиляции генерируется измененный объектныйфайл (object file) и новый символьный файл (symbol file).

В последнем содержится информацияоб экспортируемых объектах, которая впоследствии используется при компиляции модулейклиентов данного модуля. Генерирование нового символьного файла должно управлятьсяспециальной опцией компилятора, поскольку новая версия такого файла сделаетнедействительной компиляцию всех модулей-клиентов.Понятие основной программы не вошло в язык Oberon. Ее место занял набор модулей, связанныхдруг с другом через механизм экспорта-импорта и содержащих процедуры без параметров. Этипроцедуры рассматриваются как независимо активируемые и они называются «командами».Активация имеет вид «M.P», где «P» обозначает команду, а «M» — содержащий ее модуль.Результат работы команды рассматривается не просто как обычный прием входных данных дляосновной программы и трансформирование их в выходные, а как изменение состояния,выражаемого глобальными данными.ОператорыОператор WITH языка Modula-2 также не вошел в Oberon.

Также как и в случае симпортируемымиидентификаторами,здесьпредпочтительноявноеуказаниеполяидентификатора. В Oberon была введена другая форма оператора WITH; она носит совершенноиную функцию, называется локальным охранником (regional guard) и будет затронута позднее.Отказ от оператора FOR — другой пример разрыва древней традиции. Замысловатый механизмоператора FOR, принятый в языке Algol-60, был значительно упрощен в языке Паскаль (и вModula). Незначительная практическая ценность этого оператора привела к тому, что в Oberon онотсутствует.Низкоуровневые средстваModula обеспечивает доступ к машиннозависимым средствам через низкоуровневые конструкции,такие, как типы данных ADDRESS и WORD, абсолютные адреса переменных и функцииприведения типов. Большинство из них содержится в модуле, который называется SYSTEM.Предполагалось, что эти средства будут использоваться крайне редко, и заметить использованиеих в программе можно будет легко по наличию идентификатора SYSTEM в списке импорта.Однако практика показала, что значительное число программистов импортирует этот модульвесьма неразборчиво.

Особенную опасность здесь составляют функции приведения типов (typetransfer functions).Предпочтительно отказывать в претензии на переносимость тем программам, которыеимпортируют «стандартный», но системнозависимый модуль. По этим причинам функцииприведения типа, которые обозначались идентификатором соответствующего типа, в Oberon невошли, а модуль SYSTEM был ограничен предоставлением нескольких машиннозависимыхфункций, которые обычно компилируются в прямые вставки (inline code). Типы ADDRESS и WORDбыли заменены типом BYTE, для которого правила совместимости несколько ослаблены. Каждаяреализация языка может предоставлять в модуле SYSTEM и свои дополнительные средства.Использование модуля SYSTEM делает программу явно зависящей от реализации и следовательнонепереносимой.МИР ПК – ДИСК.

2003. № 8. СТУДИЯ ПРОГРАММИРОВАНИЯ4/12ИСКУССТВО ПРОГРАММИРОВАНИЯАВГУСТ 2003ПараллельностьСистема Oberon не требует никаких языковых средств для описания параллельных процессов.Следовательно соответствующим зачаточным средствам языка Modula, в частности, сопрограммам(coroutine), в Oberon места не нашлось.

Это является всего лишь отражением наших реальныхпотребностей в данном конкретном проекте, а отнюдь не отношением к общей актуальностииспользования параллельности в программировании.Средства, введенные в OberonНа фоне большого числа не вошедших в язык средств нововведения в количественномвыражении выглядят крайне скромно. Наиболее важными концепциями явились расширениетипов (type extension) и включение типов (type inclusion). Кроме того, открытые массивы могутиметь несколько измерений (индексов), тогда как в Modula могло быть только одно.Расширение типовНаиболее важным добавлением является механизм расширенных типов записи. Он позволяетконструировать новые типы на основе уже существующих и задает определенную степеньсовместимости между новыми и старыми типами. Предположим, что у нас имеется типT = RECORD x,y: INTEGER ENDВ дополнение к существующим полям могут быть заданы новые:T0 = RECORD (T) z: REAL ENDT1 = RECORD (T) w: LONGREAL ENDЗдесь определяются типы с полями x,y,z и x,y,w соответственно.

Мы говорим, что тип T’T’ = RECORD (T) <описание_полей> ENDявляется (прямым) расширением типа T, и наоборот, T называется (прямым) базовым (base)типом для T’. Расширенные типы, в свою очередь, могут быть сами расширены. Из этого вытекаетследующее определение.Тип T’ является расширением типа T, если T’ = T или если T является прямым расширениемрасширения типа T. И наоборот, T является базовым типом для T’, если T = T’ или если Tявляется прямым базовым типом базового типа для типа T’.

Это отношение мы обозначаем T’—>T.Правило совместимости по присваиванию устанавливает, что значения расширенного типа могутприсваиваться переменным его базового типа. Например, запись типа T0 может быть присвоенапеременной типа T. Это присваивание затрагивает только поля «x» и «y» и по сути осуществляетпроекцию значения на пространство, определяемое базовым типом.Важно разрешить модулям, которые импортируют базовый тип, иметь возможность самимопределять расширенные типы.

На практике это вполне нормальная ситуация.Концепция расширенного типа данных с особой силой проявляется в случае работы суказателями. Соответственно мы говорим, что ссылочный тип P’, указывающий на T’, расширяетссылочный тип P, если P указывает на тип T, который является базовым по отношению к T’.Правило присваивания справедливо и для этой ситуации. Теперь стало возможным формироватьтакие структуры данных, узлы которых имеют различающиеся типы, иными словами,МИР ПК – ДИСК. 2003. № 8.

СТУДИЯ ПРОГРАММИРОВАНИЯ5/12ИСКУССТВО ПРОГРАММИРОВАНИЯАВГУСТ 2003неоднородные структуры данных. Неоднородность автоматически появляется за счет того, чтоузлы соединены через указатели с общим базовым типом.Как правило, ссылочные поля размещаются в структуре элемента базового типа T, а процедуры,обеспечивающие работу с данной структурой, определяются в том же самом (базовом) модуле,где описан тип T. Отдельные расширения (варианты) определяются в клиентных модулях вместес процедурами, оперирующими с узлами расширенного типа. Такая схема находится в полномсоответствии с понятием расширяемости системы (system extensibility): новые модули,определяющие новые расширения, могут быть добавлены в систему, не требуя ни изменениябазовых модулей, ни даже их перекомпиляции.Доступ к отдельному узлу через указатель, связанный с базовым типом, обеспечивает толькопроецируемый взгляд на данные узла, а потому необходимо средство для расширения этоговзгляда.