Программы, написанные на языке программирования Оберон, требуют определённой поддержки во время выполнения — им необходим динамический загрузчик и централизованно выполняемый автоматический сборщик мусора, для этого программам на языке Оберон нужна специальная операционная среда. Обычным способом её реализации является добавление в систему набора библиотек, реализующих необходимые компоненты, хотя, вообще говоря, операционной среде вовсе не обязательно нужна отдельная операционная система: она сама по себе может представлять собой операционную систему. Таковы системы Native Oberon для первоначального Оберона и A2 для Активного Оберона. На данный момент существуют компиляторы Оберон в байт-кодвиртуальной Java-машины и CLI для виртуальной машины .NET.
На основе Оберона были разработаны проекты Оберон-0, Оберон-X и другие[3]. Простота Оберона и наличие исходных текстов оригинальной реализации позволяют легко адаптировать его для специальных классов задач. Но все эти Обероны очень близки между собой, поскольку и первоначальный Оберон очень прост.
По словам Вирта, первоначально систему хотели писать непосредственно на Модуле, но пришли к выводу о необходимости её доработки и сокращения, что и привело к появлению Оберона[5].
Целью проекта (англ.Project Oberon) Никлауса Вирта и Юрга Гуткнехта в 1986—1989 годы[6] было создание с нуля обозримой и надёжной операционной системы для однопользовательской рабочей станции.
Для реализации этого проекта в 1988 году Никлаусом Виртом был спроектирован язык программирования высокого уровня общего назначения, также названный Оберон[7].
В 1989 году в Швейцарской высшей технической школе Цюриха (ETH) была выпущена первая реализация Оберона для процессоров семейства NS32000. Он был создан в качестве компонента операционной среды Оберон. Этот компилятор требует менее 50 Кбайт памяти, состоит из 6 модулей общим объёмом около 4000 строк и сам себя компилирует за 15 секунд на компьютере с процессором NS32532 (тактовая частота — 25 МГц).[источник не указан 942 дня]
Просто невозможно поблагодарить всех тех, кто так или иначе подпитывал своими идеями то, что теперь называется Oberon. Большинство идей пришло от использования и изучения существующих языков, таких как Modula-2, Ada, Smalltalk и Cedar, которые часто предостерегали нас от того, как не надо делать.Никлаус Вирт[5]
Язык сохранил основные черты синтаксиса Модулы и был объектным расширением. Это позволило отказаться от механизма вариантных записей Модулы, являющихся отступлением от первоначальной строгойстатической типизации, что дало возможность ввести механизм автоматического управления памятью — сборку мусора: из языка исключена возможность освобождения динамически выделенной памяти с помощью особого оператора, а вместо него сама среда исполнения содержит модуль, возвращающий неиспользуемую память системе. Автоматическое управление памятью является средством повышения надёжности программ с динамическими структурами данных, так как исключает человеческие ошибки, свойственные, например, таким языкам, как С/C++.
Чтобы добиться наибольшей надёжности и производительности трансляции, было предпринято значительное упрощение языка за счёт его отказа от средств, которые были сочтены ненужными (исходя из опыта разработки, реализации и применения других языков), либо усложняли компилятор без достаточного оправдания с точки зрения производительности, либо были достаточно сложны, чтобы быть отправленными во внешние библиотеки, либо плохо совмещались с механизмами модульности и автоматического управления памятью: записи с вариантами, перечислимые типы, типы-диапазоны, множества общего вида, беззнаковый целый тип, локальные модули, модули определений, списки экспорта, оператор for, прежний вариант оператора with, специальный синтаксис определения главной программы. Рудиментарные средства поддержки параллельного программирования, имевшиеся в Модуле-2, не вошли в язык, так как он обслуживал однопользовательскую операционную систему. В целях упрощения отказались от обработки исключений.
Было упрощено описание массивов (индексы массивов могут быть только целочисленными и всегда начинаются с нуля, подобно языку Си), ограничено использование указателей — указатели могут существовать только на записи и массивы, в списках импорта указывается только импортируемый модуль, а при использовании импортированных имён требуется обязательная квалификация (явное указание имени модуля-экспортёра).
В статье «От Модулы к Оберону»[5] Вирт подробно пояснил причины удаления каждого из элементов.
Из соображений «достаточного минимума» в язык не были включены в качестве явного синтаксического понятия методы (процедуры и функции, связанные с типом), так как этот механизм в самом общем виде легко смоделировать, создавая в объектах (записях в языке Оберон) поля процедурного типа и присваивая им процедуры, соответствующие методам. Таким образом, в Обероне минимальными средствами поддерживается объектно-ориентированное программирование для упрощения процесса трансляции кода и ускорения этого процесса.
Благодаря внесённым изменениям, Оберон стал синтаксически проще. Описание его синтаксиса поместилось на одной странице, полное описание языка занимает около 20 страниц, что вдвое меньше, чем описание Модулы-2. Оберон является если не минимальным, то, во всяком случае, одним из самых малых по объёму универсальных языков программирования высокого уровня.
Эпиграфом к описанию оригинального Оберона было выбрано высказывание Эйнштейна: «Делай настолько просто, насколько возможно, но не проще этого».
Список импорта определяет, из каких модулей будут импортированы внешние имена. Определения включают определения типов, процедур, функций, переменных, констант. При этом определения имён, отмеченных звёздочкой, экспортируются данным модулем, то есть будут видны другим модулям, импортирующим данный. В Обероне-2 допустимо также помечать имена знаком минус, в этом случае они экспортируются в режиме «только для чтения».
Тело модуля исполняется при его загрузке. В Компонентном Паскале внутри тела модуля (в разделе BEGIN..END) появилась возможность добавить секцию CLOSE:
BEGINОператорыCLOSEОператорыENDИмя.
Здесь операторы, расположенные между BEGIN и CLOSE, выполняются при загрузке модуля, а операторы, расположенные между CLOSE и END — при выгрузке его из памяти. Такое расширение было сочтено полезным для компонентных программ, которые загружают и выгружают модули динамически.
Создаваемые программистом типы данных ограничены следующим набором: типы-массивыARRAY, типы-записиRECORD, процедурные типыPROCEDURE, типы-указателиPOINTER. Указатель может быть объявлен только на массив или запись.
Синтаксис внутренней части программы достаточно традиционен и прост. Язык поддерживает традиционный набор конструкций: условный оператор IF, оператор выбора CASE, циклы (с предусловием — WHILE, с постусловием REPEAT..UNTIL, безусловный — LOOP). Подобно Модуле-2, прописные и строчные буквы в идентификаторах различаются, все зарезервированные слова пишутся большими буквами. Все языковые конструкции, кроме цикла REPEAT..UNTIL заканчиваются ключевым словом END и допускают расположение внутри нескольких операторов без использования составного оператора BEGIN..END. Естественно, как и в Модуле-2 нет безусловных переходов.
Парадигма объектно-ориентированного программирования поддерживается механизмом расширения записей (в языке нет отдельного ключевого слова для описания классов, вроде «class» или «object», сочтено, что обычного понятия «тип запись» вполне достаточно). По сути, каждый тип запись — это описание класса, а поля записи — это данные-члены класса.
В исходном Обероне методов (процедур и функций, связанных с классом) нет вообще. Механизм методов может быть использован путём объявления в записи полей процедурного типа, которым при создании экземпляра класса присваиваются конкретные процедуры. Вызов таких процедур производится традиционным способом обращения к полю записи, по умолчанию процедура не знает об экземпляре класса, для которого она была вызвана (нет механизма, аналогичного this в C++ или Java), и если такие сведения ей необходимы, ссылка на экземпляр должна быть передана явно (например, через параметр). Отсутствие явно описываемых методов было одним из качеств исходного Оберона, вызвавшего критику привыкших к традиционным гибридным языкам программистов. С другой стороны, предлагаемый Обероном механизм позволяет реализовать всё, что реализуемо традиционными средствами языков с методами, и даже более того — в Обероне каждый экземпляр класса может иметь собственный вариант метода (значение поля процедурного типа), тогда как при описании методов как части класса все экземпляры работают с одним вариантом метода. В Обероне-2 методы были всё-таки введены. Методы описываются отдельно от типа запись, с указанием типа, с которым они связаны.
Новый тип запись может быть объявлен как расширение существующего. В этом случае тип, который расширяется, указывается в описании записи в скобках после ключевого слова RECORD. Расширенный тип автоматически получает все поля расширяемого типа и (в Обероне-2) связывается со всеми процедурами, связанными с расширяемым типом. Процедуры, связанные с новым типом, могут иметь ту же сигнатуру, что и процедуры, связанные с расширяемым типом — таким образом обеспечивается переопределение методов в порождённых типах. В Компонентном Паскале, с целью обеспечения полного статического контроля за согласованностью иерархий наследования (и этим восстанавливая принцип тотальной статической типизации, отличающий первоначальный Оберон), записи по умолчанию не являются расширяемыми, а методы не могут быть переопределены. Чтобы контролировать расширение записей и переопределение методов, используются специально введённые ключевые слова EXTENSIBLE, ABSTRACT, LIMITED, EMPTY. При этом вновь вводимые методы должны маркироваться ключевым словом NEW (ср. обязательное определение вновь вводимых переменных).
Оберон нацелен на компонентно-ориентированную разработку программного обеспечения[9]. Инкапсуляция поддерживается исключительно на уровне модуля — все типы, объявленные внутри модуля, друг для друга абсолютно прозрачны. Из других модулей доступно то, что объявлено при определении как экспортируемое.
Полиморфизм обеспечивается за счёт механизма методов (и процедурные поля в Обероне, и методы в Обероне-2 ведут себя как виртуальные, в терминологии большинства гибридных объектно-ориентированных языков), а также расширенной конструкцией WITH, позволяющей выполнять различные группы операторов в зависимости от того, к какому из расширенных типов относится её аргумент.
В языке отсутствует специальный механизм конструкторов. Рекомендуемым методом создания и инициализации объектов является описание порождающих модулей и процедур (в традиционной терминологии ООП — factory).
Программа в такой технологии представляет собой набор относительно самостоятельных компонентов (в данном случае — модулей), имеющих скрытую от внешнего мира внутреннюю структуру и чётко определённый интерфейс. Модули могут загружаться и выгружаться динамически, во время работы программы, система предоставляет развитые средства контроля типов во время выполнения, которые позволяют писать универсальные алгоритмы обработки данных, не зависящие от конкретных типов этих данных (например, библиотека для работы с СУБД может предоставлять методы, записывающие результат запроса из базы в запись произвольной структуры, если набор и типы полей этой записи соответствуют набору и типам полей в БД).
В компонентной парадигме считается неудачным архитектурное решение, связанное с широким использованием наследования реализации от типов, объявленных в другом компоненте, поскольку это приводит к явлению, известному как «хрупкость базового типа» — после того, как от базового типа порождено большое количество типов-наследников (причём часть из них может быть даже неизвестна разработчику базового типа), любые изменения в реализации базового типа становятся крайне рискованными, так как они могут непредсказуемым образом отразиться на типах-потомках.
Известно, что одной из проблем применения объектно-ориентированного программирования в системном программировании является необходимость иметь группы маленьких классов, которые могли бы взаимодействовать без дополнительных накладных расходов. В Обероне этой проблемы нет — все типы, определённые в одном модуле, видят друг друга, а проблем с надёжностью это не создаёт, так как модуль всё равно разрабатывается, тестируется и сопровождается как единое целое.
Типичная система, разработанная на Обероне, представляет собой набор модулей с процедурными интерфейсами, через которые модули обмениваются данными, в том числе и объектами. При этом все средства инкапсуляции действуют только в межмодульном взаимодействии, что делает удобным системное программирование с использованием объектов.
Объектно-ориентированное программирование
Средства объектного программирования интерпретируются в Обероне как естественное развитие средств работы с записями в модульной системе, точнее, как технический инструментарий для решения конкретной архитектурной задачи: обеспечить эффективное «разделение труда» между различными модулями при работе с динамическими типами и структурами данных: например, работа с указателями в списке может быть скрыта (вместе с соответствующими полями) в одном модуле, а определение и работа с конкретным «наполнением» элементов списка — задаваться в другом (или, чаще, других). В этом смысле технология объектного программирования в Обероне подчинена концепции модульности: она здесь является, скорее, средством описания данных, чем средством построения архитектуры приложения в целом.
По утверждению Вирта[10], разработчики языка Java за несколько лет до её создания «изучили исходные коды Оберона и, в частности, исходные коды обероновских сборщиков мусора. Потом они испортили Оберон синтаксисом Си и назвали получившееся словом Java». Хотя от устного выступления нельзя требовать абсолютной точности формулировок, но во всяком случае несомненное сходство идеологий Оберона и Java (стремление к минимализму и строгой типизации, ограничение множественного наследования, автоматическое управление памятью) говорит о том, что здесь имеет место определённый консенсус относительно того, какие средства должны составлять ядро современного языка программирования общего назначения. Однако если в Обероне и его прямых наследниках минимализм остаётся во главе угла, разработчики Java пошли по пути экстенсивного наращивания возможностей языка.
Исходная версия Оберона («классический Оберон») — наиболее краткая, с наименьшим количеством ключевых слов и синтаксических конструкций. Она была использована в качестве базы для создания семейства языков, каждый из которых расширяет классический в каком-либо направлении либо отличается от него некоторыми деталями.
В 1992 году Никлаус Вирт и его ученик Ханспетер Мёссенбёк — ныне профессор Университета им. Иоганна Кеплера в Линце — опубликовали описание дополненного варианта Оберона, получившего название Оберон-2. Он представляет собой уточнённую версию классического Оберона. Дополнения, внесённые в Оберон-2 и оформленные очень экономно, заключаются в следующем:
добавлены процедуры, связанные с типом, допускающие переопределение для порождённых типов (приблизительный аналог виртуальных методов в других объектно-ориентированных языках);
добавлена возможность экспорта описаний в режиме «только для чтения»[11][12].
Несмотря на расширение языка, объём формального описания синтаксиса Оберона-2 меньше, чем у классического Оберона за счёт оптимизации описания синтаксиса.
Существует оптимизирующий компилятор XDS[13] для Оберона-2; есть также компилятор[14] в байт-код Java.
Oberon SA — это версия языка Оберон, разработанная Н. Виртом для процессора Strong-ARM, используемого в беспилотном вертолете.
На основе опыта разработки Oberon SA Н. Вирт в 2007 году подготовил изменения и дополнения к классическому Оберону[15][16] для более строгой поддержки структурного программирования, чем, например, в Oberon-2 или Компонентном Паскале. Новая версия языка получила название Oberon-07[17]. Имеется перевод «The Programming Language Oberon, Revision 1.11.2008» на русский язык[18]. Но в отношении поддержки объектно-ориентированного программирования язык Oberon-07 не следует за Обероном-2, а продолжает минималистичную линию классического Оберона, включая отсутствие поддержки процедур, привязанных к типам записей.
Oberon-07 имеет следующие основные отличия от классического Оберона:
в цикле WHILE разрешены несколько охраняемых ветвей (ELSIF … DO). Тем самым обеспечена полная явная поддержка цикла Дейкстры[19]. Ранее цикл Дейкстры моделировался при помощи цикла LOOP;
соответственно, исключен неструктурированный цикл LOOP вместе с оператором EXIT (выход из цикла);
в процедуре теперь может быть только одна точка выхода, фиксированная в конце тела процедуры: RETURN, в сущности, перестал быть оператором, превратившись в такую же синтаксическую часть описания процедуры, как ключевое слово PROCEDURE и т. д.;
добавлен оператор цикла FOR;
исключено неявное приведение типа INTEGER к REAL и типов с различной разрядностью друг к другу;
разрешены ссылки только на записи;
определены процедурные переменные—могут ссылаться только на процедуры;
уточнено правило импорта/экспорта: экспорт переменных разрешён только для чтения, спецификатор экспорта один — «*»;
уточнены типы данных — CHAR поддерживает множество Latin-1, INTEGER — −2^31 — +2^31-1, REAL и LONGREAL — IEEE Standard, 32 и 64 бита соответственно, SET — множество целых между 0 и 31. В последнем описании языка[20] Вирт отказался от указания конкретного диапазона значений для базовых типов: множество значений типов INTEGER, REAL, LONGREAL и SET теперь определяется реализацией, тип CHAR содержит «стандартный набор символов» («a standard character set»).
Австралийская компания CFB Software (г. Брисбен) при Университете штата Квинсленд разработала IDE Astrobe[21] для языка Oberon-07 для микроконтроллеров ARM7 компании NXP (Philips) и синтаксические диаграммы языка Oberon-07[22], а также рекомендации по стилю программ на Oberon-07[23].
Оберон-2 сразу после опубликования в 1992 году рассматривался как кандидат на роль стандарта языка (конференция Oakwood Conference, Croydon, 1993), но практический опыт, накопленный при создании больших программных комплексов, выявил необходимость уточнения/расширения конструкция языка. Это лишний раз подчёркивает мудрость консерватизма, проявленного Виртом в определении классического Оберона.
Эти уточнения были предприняты в расширении Оберона-2, названном Компонентный Паскаль и опубликованном в 1999 году, компанией Oberon microsystems[24], образованной в 1992 году учениками Вирта (сам Вирт стал членом совета директоров). Как и при переходе от Оберона к Оберону-2, эти уточнения сделаны наиболее экономно[25]. Код на Компонентном Паскале может быть редуцирован к подмножеству, эквивалентному первоначальному Оберону или к другому полноценному минималистичному подмножеству, в котором наследование и переопределение методов допускается только для чисто интерфейсных типов и методов (определённых с атрибутом ABSTRACT).
В Компонентный Паскаль добавлены средства, позволяющие разработчику полностью контролировать расширение экспортируемых типов и переопределение методов (атрибуты EXTENSIBLE, ABSTRACT, NEW, EMPTY, а также возможность ограниченного экспорта метода «только для реализации»). Добавлен блок завершения тела модуля (ключевое слово CLOSE) и предопределённый пустой метод FINALIZE. Система основных (элементарных) типов приведена в соответствие с типами Java. Введён неявный строковый тип.
Компания Oberon Microsystems, определившая Компонентный Паскаль, выпустила также фреймворк BlackBox Component Framework и среду визуального программирования BlackBox Component Builder[26] — небольшие по размеру и нетребовательные к ресурсам, целиком построенные на Компонентном Паскале.
Впоследствии компилятор BlackBox был встроен в кросс-платформенную среду программирования Denia, в частности для операционной системы реального времениJBed, полностью написанной на Компонентном Паскале.
Эти языки уже с полным основанием можно назвать не расширениями или версиями Оберона, а самостоятельными языками. В них существенно расширен синтаксис, введены конструкции для описания классических «свойств» (property) с контролем чтения/записи, числовых типов с задаваемым размером в битах. Введена поддержка активных объектов, обменивающихся сообщениями в формате, определяемом РБНФ-описанием, обработка исключений[27].
↑Wirth, N. Modula-2 and Oberon // HOPL III : Proceedings of the third ACM SIGPLAN conference on History of programming languages : [англ.] : [арх. 22 декабря 2012]. — ACM, 2007. — June. — P. 3-1–3-10. — doi:10.1145/1238844.1238847.
↑ 123Вирт, Н.От модулы к Оберону. = Niklaus Wirth. From Modula to Oberon. Institute for Computer Systems, ETH, Zurich, Technical Paper. 1990. : [пер. с англ.]. — ИнфоАрт, 1998.
↑Wirth, N. Project Oberon : [англ.] / N. Wirth, J. Gutknecht. — New York : Addison-Wesley, 1992.
↑Wirth, N. The Programming Language Oberon. : [англ.] // Software — Practice and Experience : журн. — Vol. 18, no. 7. — P. 671–690.