OberonCore

Господа, а как вы трактуете/понимаете вот этот пункт:

А в чем затруднение?

Затруднение в трактовке этого пункта

Ну, например, что значит "dynamically"? Предположим у нас есть некая процедура (или не процедура, а некое ключевое слово, не важно) вроде LoadModule. Так вот, является ли достаточным реализовать LoadModule параметром которой будет строковый литерал (т.е. строка известная на этапе компиляции модуля, например LoadModule("MyModule')), или же Appendix D требует чтобы LoadModule был реализован в т.ч. и для не константных строк (т.е. строк которые могут быть сгенерированы во время исполнения программы, в т.ч. и путем пользовательского ввода)?

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

"retrievable" не имеет отношения к загрузке модулей. Здесь речь о получении списка (уже) загруженных модулей в ран-тайм, плюс базовой метаинформации о них. XDS этому пункту соответствует, но все модули линкует статически (кроме DLL).

Забавно, не думал что расхождение в формулировках и понимании столь глубоко

Вот "официальный" перевод этого фрагмента на русский:


Ни про метаинформацию, ни про список загруженных модулен. Ничего вообще.

"доступны динамически" лично я интерпретировал, как: мы имеем право получить доступ к тому чего небыло на этапе компиляции. Т.е. мы можем сказать LoadModule("MyModule") (т.е. на этапе компиляции мы конечно знаем это самое слово -- MyModule, но о самом модуле ни сном ни духом), и затем у этого самого модуля дернуть пару-тройку процедур, ака команд.

Т.о. про метаинформацию нет ничего (кроме разве что имен модулей (а эта метаинформация может быть просто в имени файла модуля) и сигнатур процедур-команд), зато про загрузку модулей есть вполне:



Вот этот пункт целиком + перевод:

Все-таки имеет.

В этом фрагменте просто явно оговаривается обязательная в Оберонах, но не вполне родная для традиционных систем возможность вызывать команды, полные имена которых (Модуль.Команда) к моменту вызова материализуются "из ниоткуда".

Никаких дополнительных смыслов искать тут на свою голову не следует.
Хотя, конечно, хочется, -- когда такая базовая вещь жуется в столько слов...

Эмм.. Это как? Т.е. я могу не импортируя никаких модулей написать в коде ту самую MyModule.Cmd и оно само попробует найти нужный модуль и вызвать эту процедуру?

С чего вы взяли LoadModule? Там говорится скорее о FindModule("MyModule"). "Доступны динамически" не новые модули, которых не было в момент компиляции, а информация о доступных на момент исполнения модулях.Цитаты хорошие, только надо внимательно читать. Во-первых, про метаинформацию там есть (meta information), во-вторых:Может будут загружены, а может и не будут - в зависимости от реализации. Слово "may" означает "может", а не "должен". Отдельно проговорено, что в случае встроенных систем никакой загрузки ожидать не приходится, т.е. это возможность дополнительная. А основная возможность, как я и говорю, - в том, чтобы получить ссылку на модуль по имени, если модуль с таким именем присутствует (в памяти или, если есть динамический загрузчик, на диске), а потом уже найти там по имени нужную команду или экспортированный тип.

Смотрим на реализаицю XDS. Напомню, что в XDS только статическая линковка. Описание модуля oberonRTS.
PROCEDURE Search(name: ARRAY OF CHAR): Module;
(* Returns a module by its name or nullModule. *)
PROCEDURE ThisCommand(m: Module; name: ARRAY OF CHAR): Command;
(* Returns the command (parameterless procedure) named "name" in the module m or NIL, if the command does not exist. *)

Пример кода (только что накидал, не компилировал):
RunCmd ('MyModule', 'MyCmd'); (* Выполнится MyModule.MyCmd при условии, что модуль MyModule прилинкован и содержит экспортированную процедуру MyCmd без параметров. Тот, кто вызывает RunCmd не обязан импортировать MyModule ни прямо, ни косвенно. Вот это и есть "retrievable dynamically", не путайте с "loadable dynamically". *)

Не понимаю вашего удивления. Любой коммандер в BlackBox именно это и делает. Только не напрямую в коде надо писать, а через доступ к метаинформации (модуль Meta в BlackBox, oberonRTS в XDS) получить ссылку-указатель на процедуру, затем её по указателю вызвать.

А собственно при чем тут BB? Мы обсуждаем language report. Судя по формальному описанию синтаксиса в КП всё есть модуль, вне модуля нет ничего. А поскольку команда это обычная процедура без параметров которая при этом экспортируется (это явно описано), делаю вывод что команда вызывается в точности также как и любая процедура. Учитывая замечание Info21, приходим к выводу что можем вызвать процедуру явно не импортируя её модуль. Просто написать в своей функции/процедуре MyModule.Cmd, и оно будет вызвано (при необходимости модуль MyModule будет в этот момент загружен), или не будет вызвано и у нас случится UB, если модуль с таковым именем не будет найден.

Но приложение формулирует обязательные требования к среде исполнения.

Да. Вот и пытаемся выяснить что же это за требования такие.

Нигде не описано где писать эти самые Module.Cmd, т.е. не описана командная оболочка, следовательно делаем вывод что это не оно имеется тут ввиду. А нечто другое.

Видимо под "Mandatory Requirements for Environment" подразумеваются требования к рантайму. Т.е. сборка мусора там, типизация времени исполнения и прочее что касается непосредственно ИСПОЛНЕНИЯ данной программы писаной на КП. Но никак не шелл программиста или пользователя.

Вообще-то мы обсуждаем не language report, а приложение к нему. И приложение это посвящено рантайм-окружению, не являющемуся частью языка. Вот цитата:Жирным выделил я, курсив авторский.

Во-первых, не вижу логики, во-вторых, вспоминаем приведённую вами ранее читату:Языком не задаётся, т.е. как реализуете, так и будет. Как реализовано в BlackBox и XDS я вам вкратце описал. В ОС Oberon реализовано примерно так же.

Штука в том, что конкретно этот подфорум посвящен не Oberon-2, а Component Pascal т.о. мы обсуждаем language report CP.

И там сказано следующее:

Прошу прощения, я что-то думал про Oberon-2, а не про КП. Невнимательность с моей стороны.В последнем предложении "compliant" по смыслу можно заменить на "compatible". Т.е. это минимальные требования к среде, чтобы она была совместима с языком КП, но среда не становится от этого частью языка.

Да нет, это не минимальные требования к среде, это минимальные требования к реализации (implementation), которая должна удовлетворять как компиляторным требованиям так и к требованиям "средовым".

Опять же, цитата из "официального" перевода:

Коллеги, среду от реализации оторвать нельзя, философия учит.
Так что правы обое двое

Подводя некий (предварительный?) итог:

1) При компиляции компилятор должен сохранять информацию о имени модуля + списка экспортируемых процедур с из полными сигнатурами. Причем это так даже для статически скомпонованого приложения.

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

3) Если у нас не статически скомпонованое приложение, то обязателен динамический загрузчик модулей. (гм. что вообще говоря логично, интересно как можно в рантайме загрузить модуль не имея динамического загрузчика? или же тут подразумевается что уж динамический загрузчик то рантайм должен предоставлять, а не заставлять реализовывать его программиста?)

Всё верно?