Modula2 vs Oberon

ИСКУССТВО ПРОГРАММИРОВАНИЯАВГУСТ 2003Никлаус ВиртОт Modula к OberonNiklaus Wirth (1990) From Modula to Oberon // Institute for Computer Systems, ETH, Zurich.Р. Богатырев, перевод с англ.Язык программирования Oberon является результатом концентрированных усилий по увеличениюмощности языка Modula-2 и одновременно по уменьшению его сложности. Несколько средствбыло удалено, другие же были добавлены, в результате чего возросла выразительная мощностьязыка и повысилась его гибкость.

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

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

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

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

Идя по эволюционному пути развития, ане по революционному, мы сохраняли традиции длительной разработки, которые идут от Algol кПаскалю, затем к Modula-2 и, наконец, к Oberon. Общая характерная черта всех этих языков —это их процедурная, а не функциональная модель, а также жесткая типизация данных. Ещеболее фундаментальной является идея абстракции: язык должен определяться в терминахматематических, абстрактных концепций без ссылки на какой бы то ни было вычислительныймеханизм. И только если язык удовлетворяет этому критерию, он может называтьсяМИР ПК – ДИСК.

2003. № 8. СТУДИЯ ПРОГРАММИРОВАНИЯ1/12ИСКУССТВО ПРОГРАММИРОВАНИЯАВГУСТ 2003«высокоуровневым». Решительно никакая синтаксическая глазурь не в силах заставить языкобойтись без этого атрибута.Описание языка должно быть стройным и лаконичным. Этого можно достичь лишь путемаккуратного выбора соответствующих абстракций и подходящей структуры, которая позволяет ихкомбинировать. Руководство по языку должно быть весьма коротким и должно избегатьпояснения частных случаев, проистекающих из общих правил. Мощь формализма не должнаизмеряться длиной описания.

Более того, чересчур пространное описание — это характерныйсимптом двояких толкований. В этом плане целью должна быть не сложность, а простота.Несмотря на свою краткость описание должно быть законченным. Полнота должна достигаться врамках выбранных абстракций. Ограничения, накладываемые конкретными реализациями, неотносятся собственно к описанию языка. Примерами таких ограничений являются максимальныезначения чисел, арифметические ошибки округления и усечения, действия, предпринимаемые втех случаях, когда программа нарушает установленные правила. Не должна проявлятьсяпотребность в таком дополнении к описанию языка, когда толстенные описания стандартовпокрывают «непредвиденные» ситуации.В то же время язык программирования не должен быть одной лишь математической теорией.

Ондолжен быть практическим инструментом. Это подразумевет определенные ограничения,накладываемые на краткость формализма. Несколько языковых средств Oberon с чистотеоретической точки зрения являются излишними. И, тем не менее, они присутствуют в языке изсугубо практических соображений, то ли для удобства самого программиста, то ли длядостижения эффективной кодогенерации без использования в компиляторах сложных«оптимизирующих» алгоритмов сопоставления шаблонов. Примерами таких языковых средствявляются наличие нескольких форм оператора цикла, а также существование стандартныхпроцедур, таких как INC, DEC и ODD.

Они не усложняют ни язык, ни компилятор.Все эти аргументы нужно иметь в виду, когда производится сравнение Oberon с иными языками.Ни язык, ни описывающий его документ не достигают идеала; но Oberon приближается к этойцели гораздо лучше своих предшественников.Компилятор для Oberon был реализован для процессоров семейства NS32000 и был встроен воперационную среду Oberon [2]. Этот компилятор требует менее 50 Кбайт памяти, состоит из 6модулей, общим размером около 4000 строк исходного текста и сам себя компилирует примерноза 15 секунд на рабочей станции с 25 МГц процессором типа NS32532.После многочисленных экспериментов в программировании на языке Oberon был определен иреализован его новый вариант.

Различия между этими двумя версиями собраны в конце даннойработы. Далее мы приводим краткое введение в (пересмотренный) Oberon для тех, кто знаком сModula (или Паскалем), концентрируясь при этом на добавленных средствах и перечисляя те,которые были из Modula удалены. А чтобы было более понятно, начнем с изъятых средств.Языковые средства, удаленные из ModulaТипы данныхУдалены вариантные записи, поскольку они создают серьезные трудности для реализациинадежной системы распределения памяти, основанной на автоматической сборке мусора.Функциональность вариантных записей сохраняется за счет введения расширяемых типовданных.Скрытые типы служат концепции абстрактных типов данных и инкапсуляции информации. Онитакже удалены, поскольку их заменяет новое средство расширенных типов записи.Тип перечисление — слишком простое средство, чтобы оно могло выйти из-под контроля.Однако, оно не позволяет распространять расширяемость за пределы модуля.

И либо нужноввести средство для расширения типа перечисление, либо же от типа перечисление надобноотказаться. Причина, по которой мы выбрали второй путь — путь радикального решения —кроется в том, что во все возрастающем числе программ непродуманное использованиеМИР ПК – ДИСК. 2003. № 8. СТУДИЯ ПРОГРАММИРОВАНИЯ2/12ИСКУССТВО ПРОГРАММИРОВАНИЯАВГУСТ 2003перечислений (и диапазонов) ведет к демографическому взрыву среди типов, что, в своюочередь, ведет не к ясности программ, а к их многословию. В связи с использованием экспорта иимпорта перечисления приводят к исключению из правил, и согласно ему импортидентификатора типа также приводит к автоматическому импорту всех связанных с типомидентификаторов констант. Это исключение нарушает концептуальную простоту и создает дляреализаторов языка неприятные проблемы.Типы диапазонов были введены в Паскале (и сохранены в Modula) по двум причинам: (1) чтобыподчеркнуть тот факт, что переменная принимает значения из ограниченного диапазона базовоготипа, и чтобы дать возможность компилятору генерировать соответствующий проверочный коддля присваиваний; (2) чтобы позволить компилятору выделять минимально необходимоепространство памяти для хранения значений из указанного диапазона.

Это желательное свойствов плане использования упакованных записей. Лишь в небольшом числе реализаций используетсяданное преимущество экономии памяти, поскольку при этом компилятор довольно значительноусложняется. Причины под номером 1 явно недостаточно, чтобы оставить в Oberon работу сдиапазонами.Ввиду отсутствия перечислений и диапазонов избыточным выглядит возможность определятьмножества на основе данного типа элементов. Вместо этого в язык был введен лишь атомарныйтип SET, значениями которого выступают множества целых чисел в диапазоне от 0 до некоторогомаксимального значения, определяемого реализацией.Атомарный тип CARDINAL был введен в Модулу, чтобы позволить на 16-разрядных компьютерахработать с адресной арифметикой в диапазоне от 0 до 216.

В связи с преобладанием всовременных процессорах 32-разрядных адресов необходимость в беззнаковой арифметикепрактически отпала, а потому тип CARDINAL в язык Oberon не вошел. Одновременно с этимисчезли и проблемы несовместимости операндов типов CARDINAL и INTEGER.Ссылочные типы теперь могут строиться как указатели лишь на записи и массивы.Понятие определяемого программистом типа индексов для массивов также не вошло в Oberon:теперь все индексы могут быть только целыми числами. Более того, нижняя граница индексовтеперь строго равна 0 и в описании массива фигурирует только количество элементов, а не паразначений, определяющих границы индексов. Этот отход от уже устоявшейся традиции,восходящей своими корнями еще к языку Algol-60, наглядно демонстрирует принцип удаления изязыка всего несущественного.