OberonCore

В проекте Where, написанном на ETH Oberon, встречается такой код:

И сразу возникли вопросы.

Сначала: BlackBox такое скомпилирует если в первом указателе запись пометить как EXTENSIBLE.

Ofront (Оберон-2), напротив, не компилирует — ошибка "identifier does not denote a type".

Pow! компилирует.

XDS не компилирует. Требует присутствия END перед "(Compilation)".

В общем, закономерности я не заметил. А что говорит стандарт Оберона/Оберона-2 по этому поводу? Прокомментируйте, пожалуйста. И с точки зрения: нужна ли эта фича в Обероне/Обероне-2 по вашему мнению? — для упрощения при описании только динамических структур (не требуется отдельно описывать NodeDesc = RECORD и Node* = POINTER TO NodeDesc). И с точки зрения: как это реализовано в Обероне-07, и почему. Возможно, будут ещё какие мысли.

Интересуюсь с целью: вводить ли поддержку данной фичи в мой форк Ofront'а?

В справке ББ про это написано.

Это было сделано в CP просто для удобства, чтобы не описывать запись и указатель на нее отдельно.
Oberon 2 такое компилировать не должен по идее

В Oberon-07, насколько я понимаю, так нельзя.
В принципе в этом даже есть преимущество, исчезает необходимость в слове EXTENSIBLE.
То есть, если, допустим, есть тип:
Rec* = RECORD ... END;
То он может быть расширен, до
ExtRec* = RECORD (Rec) ... END;
Но, если есть тип
PtrRec* = POINTER TO RECORD ... END;
то расширить его уже не получится.

Ну и в чём же здесь преимущество отсутствия EXTENSIBLE, если расширять нельзя только динамические типы?

В случае, когда один тип записи определен в одном модуле, а расширяется в другом модуле, тоже можно запретить расширение - просто не эксортировать этот тип и всё. А если экспортируется обычный тип запись, то и расширить можно. А если хочется экспортировать, но запретить расширять, то экспортировать как указатель на запись.
Как мне кажется, расширение записей идет в ногу с динамическими структурами данных. Пока не могу представить себе пример, когда используются расширенные записи без указателей на них.
Если кто-нибудь может привести такой пример, то был бы рад узнать о нем.

Указатель может быть в виде VAR-параметра, без объявления типа POINTER TO. Например, расширяемые типы Reader и Writer в системе Оберон были, как правило, стековые. В этом случае их можно сделать локальными переменными либо глобальными с повторным использованием, но без необходимости динамического выделения памяти.

Значение типа POINTER всегда можно передать в VAR-параметр, но не наоборот. Тип POINTER всегда требует NEW для выделения памяти. Я хочу сказать, что VAR более универсален.

За примером тоже далеко ходить не надо. БОльшая часть сообщений в ББ, если я правильно понимаю, сделаны на стековых - расширяемых - записях. Иначе он бы память жрал постоянно, если бы вызывал NEW на каждый чих мыши и клавиатуры. Зачем они расширяемые, думаю, не надо объяснять.

Заодно разрешив только динамику. КП с его EXTENSIBLE мне кажется более универсальным решением. Напоминаю, что свойством EXTENSIBLE можно пометить и указатель на запись, и запись, и метод. А можно не помечать. Т.е. минимализм Оберона-07 конечно похвален, зато КП даёт больше возможностей по варьированию описания экспорта. А регламентирование межмодульных взаимодействий — очень важная вещь. Я буду рад, если КП будет развиваться в этом направлении.

Здесь на форуме Илья Ермаков писал про то, что на Обероне/КП можно писать без использования указателей и нагрузки на сборщик мусора. Если можно, приводите примеры.

Решил в форке Ofront'а сделать как в КП — реализовать EXTENSIBLE.

Давайте не трогать КП.

Я имею в виду надмножества КП, возможно, под другим названием языка.

КП — не самая плохая база для создания на ней языковых надмножеств. Как и Оберон-07.

А зачем вообще может понадобится запрещать расширение записей?

Ну вообще-то, расширение от не-абстрактного класса (наследование реализации) по определению признак недодумки в проектировании. Да, в общем-то - и экспорт неабстрактного класса...

Ну а для исключений, которые всё же бывают, нужен EXTENSIBLE.

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

Если говорить о "пассивных записях" (для параметров, для сообщений и т.п.), то по-умолчанию стоит всегда ставить EXTENSIBLE.

У меня не получилось скомпилировать этот код в Pow!. Можно попросить полный пример кода?

Поправочка. Pow! не компилирует тоже - с ошибкой "Error 52: identifier does not denote a type". В принципе, я тогда, плохо зная Pow!, мог даже не заметить, что он не скомпилировал. Ну выкинул какое-то окошко позади всех, и что.