Ответ на »сообщение 4275« (Илья Ермаков)
___________________________

А полноценная параметризация в настоящий момент технически не вяжется с динамической модульностью. И "вязаться" она начнет только после одного события - перехода какой-либо из магистральных реализаций Оберонов (Ящика али Бутылки) на промежуточное представление Франца и JIT. Но пока до этого руки не доходят ни у них, ни у нас...

Это как Java чтоли? Дык она производительностью не блещет, хоть и оптимизировали они компилятор по самое нехочу. В смысле денег много в это вложили.
IMHO одно из достоинств Оберона в том, что он компилируется в нативный код. И теоретически (при наличии хороших компиляторов) можно получить высокое быстродействие.
Другое дело, что можно использовать это промежуточное представление без JIT. Для переносимости можно написать на C его интерпретатор и тогда везде, где будет С, будет и Оберон, пусть медленный. Для экспериментов с платформой сойдет.
А по мере необходимости и полноценный кодогенератор для данной платформы дописать можно.

Ответ на »сообщение 4302« (ASU)
___________________________

Ответ на »сообщение 4300« (AVC)
___________________________
Я попробую пояснить на другом примере. Если в базе данных таблица А ссылается на таблицу Б, то это не означает, что одна из таблиц «выше», а другая «ниже». Это просто связи на одном уровне... и все..

Если мы запрещаем таблице Б обратную ссылку на А, то есть, делаем связь строго однонаправленной. Если мы делаем связь однонаправленной, то подразумеваем, что ее участники неравноправны. Тот, кто импортирует, стоит в иерархии уровней системы выше того, кого импортируют.
И всегда, даже при отсутствии отдельного этапа проектирования, когда состав/структура модулей эволюционирует "методом проб и ошибок" (при "кустарном производстве" или в небольших проектах бывает и так) - слои системы четко выделяются. Есть более низкоуровневые группы модулей, есть более высокоуровневые - и все связи выстраиваются в одну сторону. И по-другому просто не получится - модульность с иерархическим импортом этому препятствует. А вот в языках без импорта хаосу не препятствует ничего. В языке с импортом, если вдруг внезапно "приспичит" сделать одноранговую перекрестную ссылку модулей, язык этого просто не позволит, и разработчик будет ВЫНУЖДЕН что-то перепроектировать, переделать - как бы ему ни хотелось сляпать на скорую руку, но компилятор неподкупен и твердо дает понять, что в архитектуре есть концептуальная ошибка. В языке без импорта будет сделана "быстрая клепка": A.cpp: include B.h, B.cpp: include A.h - и все так и покатится дальше...

Для примера. В Блэкбоксе есть такая штука DevDependencies - она показывает весь даг зависимостей, идущий от некоторого модуля, рисует графически, позволяет наглядно все "пощупать"...

Я построил даг, уходящий вверх от самого низкоуровневого модуля Kernel, и включающий в себя системные модули среды:
http://ermakov.metasystems.ru/forum/DependMap.gif

Связей много - но они не образует ничего похожего на клубок. Присутствует целый ряд слоев - и пучки "проводов", идущих с верхних слоев к нижним. Взаимодействия управляемы и в то же время эффективны, без излишней косвенности...
И это мы смотрим внутрь одной подсистемы. "Слоистость" на уровне подсистем среды еще более четкая.

При этом ББ именно пример "эволюции кластера модулей" - фактически, это многолетний эксперимент, переросший в промышленную среду... Сейчас уже видно, как можно улучшить структуру и еще более четко обозначить слои и связи...

Чтобы прочувствовать разницу между наличием в языке импорта и его отсутствием, достаточно хоть немного повозиться - даже не с исходниками! - с заголовками Линукса. Импорт в языке - это как раз-таки средство избежать "комбинаторного взрыва" зависимостей между частями программы. Средство, начинающее работать автоматически, независимо от желания или нежелания программиста, даже при написании "на коленках" программульки из четырех-пяти модулей.

Ответ на »сообщение 4288« (AVC)

Конечность является формальным признаком алгоритма.
http://ru.wikipedia.org/wiki/Алгоритм
Так что это просто ошибка. :)

А как быть сделением? В плане 1/3?

Ответ на »сообщение 4299« (ASU)
___________________________

А есть какая-то связь между «плоское» и не на одном уровне? Какие уровни модулей поддерживает Оберон?.. точнее было бы спросить так, какие уровни модулей позволяет создавать и поддерживать Оберон?..

Просто представьте DAG (частный случай дага -- дерево).
По-моему, это иерархическая структура.

Ответ на »сообщение 4298« (ASU)
___________________________

Поясню... Много раз я говорил, что должны быть уровни. Это ограничение и ограничение жесткое. Много раз я говорил, что элементы (модули) одного уровня не должны прямо взаимодействовать друг с другом (должен быть, как минимум, контроль со стороны над-уровня). Это ограничение и ограничение жесткое. Эти ограничения обеспечивают надежность системы. «Вы» не поддерживаете эти ограничения... и, следовательно, отказываетесь от элементов обеспечивающих надежность, то есть, согласны на... безнадежность... :)

Здесь, возможно, какая-то терминологическая путаница.
Связь импорт-экспорт (т.е. прямое взаимодействие модулей) в Обероне всегда иерархическая (в логическом смысле -- нет "кругов в определении").
Если A определяется через B, то, IMHO, здесь сущности не совсем одного уровня.

Ответ на »сообщение 4296« (ASU)
___________________________

Это я вообще перестал понимать... в контексте предыдущего... тем более.
Если в Оберон все модули на одном уровне, то о каком верхнем уровне идет речь. Если в Оберон все модули на одном уровне, то их можно использовать как угодно (тирания, в том числе)... Где-то я потерял Вашу мысль...

Я никогда не говорил, что в Обероне все модули на одном уровне.
Если один модуль импортирует другой, то они не на одном уровне; это гарантируется ацикличностью связей импорта.
Я лишь немного сетовал на то, что "пространство имен" модулей в Обероне "плоское".