OberonCore

Кратко отвечу на некоторые вопросы:

* Возможен ли динамический массив, элементами которого являются статические массивы?
Да возможны: POINTER TO ARRAY OF ARRAY 10 OF CHAR
Проверьте по грамматике языка, это должно следовать из грамматики

* Как пользоваться ImportedProcedure?
Также можно посмотреть в грамматике и как пример файл WinApi.ob7

* На какие целевые архитектуры и ОС рассчитан компилятор (учитывая, что австралийский аналог производит исполнимый код только для микроконтроллеров)?
Расчитан на x86 под Windows

* Не помню, был ли LONGREAL в исходном Oberon-07. Если нет, то это надо указать в "добавлениях".
Было.

* Ничего не сказано о том, в какой файл помещается среда времени выполнения, а также о том, в каком формате создаются исполнимые файлы (exe, dll).
Сборщик мусора располагается в модуле Memory. Проверки времени выполнения размещены в коде, рядом с кодом, которые они проверяют. Исполнимые файлы создаются в формате PE (EXE).

* Какой аллокатор памяти используется, и если свой собственный, то как он работает.
Память запрашивается у системы, при помощи VirtualAlloc. Детали можно посмотреть в коде в файле Memory.

* Как насчет встраивания компилятора в какие-нибудь IDE или редакторы под Windows/Linux?
Под Linux компилятор пока не работает. Насчет встаивания в IDE, думаю что возможно, так как многие консольные компиляторы можно вызывать из IDE, но я этим пока не занимался.

То есть, все модули, включая модуль Memory, содержащий сборщик мусора, компилятся в один большой exe-шник, содержащий в себе и прикладную программу, и проверки времени выполнения? Правильно ли я понял?

Да, очень большой. 40Кб.
Вообще то лучше один раз пощупать чем долго выспрашивать. Компилятор доступен всем.

Только сейчас я обратил внимание на то, что обе имеющиеся реализации Oberon-07 расширяют его, в частности, динамическими массивами: Oberon for LPC2000 Microcontrollers. Может быть, и некоторые другие расширения из указанной реализации имеет смысл включить в реализацию для Windows? Не выхолащивая "дух" языка, "букву" можно подправить для расширения его потенциальной области применения. Не секрет, что Вирт всегда делал языки под какую-то конкретную текущую потребность, и им подчас не хватает универсальности. Я не призываю возвращать в язык отвергнутые по принципиальным соображениям конструкции или добавлять что-то из "неродственных" языков.

С первой частью согласен, вторую считаю ошибочной. Смотря как рассматривать универсальность.

У Вирта универсальность = баланс --- самое существенное (необходимое)/простота (make it simple but not simpler --- лучше тут не выразишь). Благодаря чему инструмент можно легко применить в произвольной области (портировать, доработать под специфику, пр.). Последнее --- доработку общего инструмента под специфику Вирт сам практикует. Как пример, его же компилятор Оберон-07: http://oberoncore.ru/wiki/lang/oberon-07

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


Почему Вирт из базы убрал дин. массивы --- значит на своём опыте счёл это средство несущественным = неоправдывающим свою сложность. Сейчас я с ним скорее согласен --- после ковыряния в кишках ББ (DevDebug) и приблизит. осознания, чего стоят дин. массивы. Остальных (в т.числе и Вас, Сергей) --- призываю сначала наработать опыт работы без дин. массивов, а потом делать выводы (насчёт нехватки универсальности).

Касательно сделать дин. массивы расширением --- автор компилятора волен делать любые расширения, какие захочет... Но опять же --- считаю, что игнорировать опыт Вирта (не прислушаться) --- глупо; его стоит проверить (касательно дин. массив = универсальное или частное средство)...

Кстати, в Виртовском комплияторе для ARM дин. массивы тоже есть в виде расширения. Cамый сложный момент отсутствует.

Выходит, Вирт не прислушался к самому себе?
Просто он более гибок и не связывает себя прецедентами.

"Выходит, Вирт не прислушался к самому себе? "
Если Вы сделали этот вывод из моего сообщения (viewtopic.php?p=62755#p62755), то Вы его не поняли. А более вероятно --- не пытались.

"Просто он более гибок и не связывает себя прецедентами."
Вирт, стараясь оставить в определении языка только самое существенное, не связывает "прецендентами" ВСЕХ (например: попробуйте сделать, реализацию компилятора стандартного Си++, как Rifat сделал Oberon-7).

Т.е. динмассивы только для связки потоков между внешним окружением программы и её внутренними переменными... программа должна брать элементы и "разносить" по внутренним структурам данных прежде, чем использовать (или класть свои результаты в элементы, дабы сделать их доступными окружению) ... а открытость длины - чтобы меньше зависеть от относительного темпа источника и потребителя?.. Кстати, в таком понимании открытость достаточна только по одному измерению вроде.

В подтверждение этой мысли:
http://oberoncore.ru/_media/wiki/lang/w ... -07.en.pdf
P.S. Одностраничная сводка про отличия Оберон-07 от Оберон и специфику виртовского компилятора Oberon-07 для ARM: http://oberoncore.ru/_media/wiki/lang/w ... nce.en.pdf