Оберон-клуб «ВЄДАsoft»

Поглядел ADW Modula-2, хорошо проработанная реализация Модулы-2 для Windows. Неплохая IDE, много настроек, в т.ч. и по оптимизации. Поддерживает юникод.

Win32 API (Samples) in ADW Modula

Некоторые выводы в процессе работы.

В Обероне не нужно перечислять все используемые процедуры, только модули, из которых они импортированы. Обязательная квалификация (т.е. W.GetDC вместо GetDC) однозначно показывает из какого модуля пришла процедура, и даже если программист забыл какой алиас какому модулю соответствует, нет необходимости искать дальше, чем в списке импорта; практика показывает, что это удобно.

В Обероне нельзя игнорировать результат процедуры, что в ряде случаев позволяет пробегая глазами код понять, что этот результат всё-таки есть и, возможно, загвоздка в нём. Кроме того, неиспользование результата процедуры — признак плохого дизайна (хотя конечно в ряде случаев это дизайн не наш — например, в WinAPI).

Для тех случаев, когда результат нам всё-таки совершенно не нужен, я разработал модуль Ignore, который позволяет игнорировать значение указанного типа, заставляя программиста задуматься хотя бы о типе игнорируемого результата. Оверхед у данного модуля нулевой, т.к. его (сишная) реализация состоит из пустых определений.

В Модуле-2 разрешено описывать проинициализированные переменные.

В ADW Modula-2 можно описывать проинициализированные массивы составной структуры (с записями внутри). В XDev благодаря расширению Олега Комлева можно эмулировать эту возможность с помощью константных массивов.

2Saferoll: Олежек, интересное замечание. Я задал константный массив, получил на него указатель (с помощью SYSTEM.ADR) и попробовал изменить значения массива. И что же: скомпилированная tcc программа спокойно работает, а вот скомпилированная MinGW вылетает с исключением по защите памяти. Из чего я делаю вывод: константные данные массива защищаются от изменений. Поэтому такой финт ушами к использованию не рекомендован, а я просто копирую данные из константного массива в неконстантный и там спокойно работаю с ними на чтение и запись.

ADW Modula-2 предоставляет возможности для строго типизированной работы с функциями WinAPI, в частности, вместо нетипизированного DeleteObject можно применить DeletePen, DeleteBrush (с проверкой типа), NULL_HWND, NULL_HBRUSH, NIL_POINT, NIL_RECT вместо обычного NIL (тоже с проверкой типа).

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

В ADW Modula-2 целочисленное деление обозначено / и это очень сильно напоминает вещественное деление.

В ADW Modula-2 больше типов, чем в XDev Oberon. Например, в последнем нет типа, который в 32-битной Windows имеет 32 бита, а в 64-битной — 64 (строго говоря, такой тип может быть, потому что разрядность типов вообще задаётся кастомно для каждого проекта, и SIZE(INTEGER) даже может быть равно SIZE(LONGINT), но поскольку я сам такое не практикую и вам не советую, то и не будем это рассматривать). Поэтому такой целочисленный тип приходится эмулировать через указатель SYSTEM.PTR. Из побочных эффектов — он инициализируется в NIL, а все значения, присваиваемые этому типу, приходится преобразовывать через SYSTEM.VAL. Но Оберон традиционно обладает небольшим числом встроенных типов. Впрочем, по мере развития проекта XDev что-то, возможно, и будет сделано в этом направлении.

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

ADW Modula-2 даёт размер Clock.exe 15360 байт, XDev Oberon — 10240 байт для 32 бит (это безо всяких упаковщиков; с UPX этот размер вообще 6656 байт) и 12800 байт для 64. Кроме того, наконец-то удалось избавиться от зависимости от msvcrt.dll

Как сгенерировать при помощи ADW Modula-2 64-битное приложение — не разобрался.

Семантически константный массив - это вещь только для чтения, что должно контролироваться транслятором. Трюк через SYSTEM.ADR обходит эти ограничения. Но сработает он или нет, зависит от реализиции. Если константный массив компилятор размещает в "памяти только для чтения" (что, вообще-то, вполне естественно), то такой обход не сработает. Так что лучше действительно никогда не применять такого.
Ну или применять по очень веским причинам (например, иначе никак в памяти данные не уместить). Но в этом случае будет привязка к техническим деталям платформы, так что, может, и в этом случае подумать об альтернативах константному массиву.

Пригодились бы инициализированные записи (и массивы таких записей), но в Обероне даже нет инициализированных переменных, причём по вполне идеологическим соображениям (разделение кода и данных). Но, в принципе, и без них всё обстоит достаточно неплохо. И я бы не взялся за реализацию всего этого в Ofront'е, нам хоть бы экспорт конст. массивов до ума довести.

Топиком показываю, что подсистема WinDev уже в чём-то обходит по возможностям ADW Modula-2. Хотя, справедливости ради, в чём-то и не дотягивает до неё.

Вообще-то в модуле-2 необязательно указывать все импортируемые сущности из модуля, как в том примере. Можно импортировать весь модуль, как в обероне, и затем точно так же использовать квалифицированные имена.
Оберон в этом плане имеет упрощённый вариант импорта из модулы-2 -- без возможности явного импорта сущностей с дальнейшим использованием без квалификации имён.

Я знаю это, наш ты гениальный.

Суть в том, что квалифицированный импорт Оберона при некоторой кажущейся избыточности (которую Вирт придумал сокращать при помощи алиасов) надёжнее (не возникает вопроса конфликта имён) и нагляднее (видно, из какого модуля эта сущность) неквалифицированного (как в Модуле-2 или Дельфи), просто к нему надо привыкнуть.

Разумеется, я знаю, что в Дельфи можно добавлять квалификатор явно. Но нет возможности подменять его алиасом. Также нет возможности заставить компилятор следить за появлением сущностей без явно указанного квалификатора.

На самом деле квалификация именем модуля не очень удачно сделана в модуле-2 и обероне -- может возникнуть путаница с именем записи какой-нибудь. Возможно, было бы лучше вместо точки для квалификации использовать другой символ или комбинацию символов -- как :: в с++, например.

Кроме того, бывает, что эта квалификация существенно портит внешний вид программы, но это актуально в основном для языков, в которых есть возможность определения собственных операторов (в смысле операций, а не statement) (как в хаскелле) или переопределения существующих (как в с++ или в аде). В обероне такого функционала нет, так что эта проблема не так ярко выражена...

Уточню: только если запись объявлена внутри модуля, а не импортирована извне (в последнем случае при обращении к элементу будет двойная квалификация: Module.record.elem). Локальные записи должны при разработке модуля крепко сидеть в памяти программиста.

Впрочем, защищать неоднозначность всё таки не буду, констатирую её. Я для различения применяю такое оформление: модули (и алиасы) — с большой буквы, записи — с маленькой. Удобно.

А в Java вместо модулей и записей применяются классы, получается, что Оберон даже разнообразнее в выразительных средствах.