OberonCore

Может я чего не понял, но доп. средства организации модулей, по-моему, нужны. Например, разрешение на межмодульное наследование реализации _только для ограниченного_ числа модулей (если уж приходится терпеть наличие такого наследования).

Ограничение на наследование реализации уже существует в Компонентном Паскале: LIMITED (еще проще -- отказ от использования EXTENSIBLE).
А вот ограничение возможности импорта конкретного модуля -- хорошая идея.
Наверное, ее можно реализовать примерно так: ввести, наряду с секцией IMPORT, секцию EXPORT, где должны быть перечислены модули, имеющие право импорта данного модуля. (Если секция EXPORT отсутствует, то модуль импортируется как обычно, без ограничений.)
Это в качестве "затравки", т.к. должны существовать лучшие решения.

Почему "должны"?
Чем это решение плохо?

(Наклевывается отдельная тема... может, сразу и выделить?)

Выделил

Это разные вопросы и ответы могут быть разные. Более общие, в том числе. В частности возможно и группирование модулей в структуры по выполняемой функции. Что-то подобное упоминалось Русланом Богатыревым в характеристиках прогнозируемого языка архитектурного уровня.
Почему бы и нет. Но лучше если в её начале будет указываться какие цели она перед собой ставит. Имхо, тем кто такие предложения о переносе выдвигает.

Например, может быть потребность в том, чтобы подсистема имела вспомогательные модули, доступные только в рамках этой подсистемы (кластера?).

Простейший пример - группа модулей наподобие Files-HostFiles чтобы HostFiles был доступен для импорта только модулю Files. И так ограничить группу Host-модулей, навроде Meta - <группа Host-Kernel модулей> причем интерфейсы модулей этой группы видят только Meta и они сами.

Кстати, Files не импортирует HostFiles. Модуль интерфейса не имеет права импортировать модуль реализации. Наоборот, модуль реализации импортирует интерфейс и суёт туда свои разъёмы....

Предложение:

Подсистемы образуют просто еще один уровень блочности (процедуры--модули--подсистемы).

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

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

А в остальном можно думать об оформлении.
Конечно, хотелось бы (если возможно) не трогать сам язык.

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

INTERNAL MODULE XxxYyyy;

(*...*)

END XxxYyy.

И наблюдаем то самое изменение языка которого очень не хотим. Причем это уже 3й вариант решения задачи в этой ветке (есть более ранняя) + вариант Руслана Богатырева + вариант языка Eiffel , очевидно, у каждого есть +/- и надо найти несколько неулучшаемых (т.е которым нельзя добавить + не добавив при этом - ) и потом уже серьезно думать какой лучше.

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

Разьве можно на уровне языка ввести некое средство, но не изменить сам язык?

На внеязыковом уровне INTERNAL модули давно есть - для таких модулей производитель не выдаёт символьных файлов, выдаёт только исполняемые.

Ну, тогда, может, и нефиг дергаться...

Есть ли реальная проблема-то?

Когда будет, тогда и решение (само) появится.

Производитель распространяет подсистему(ы) с исходными текстами и пишет в документации - модуль имеет приватный интерфейс.

Мне решение с INTERNAL нравится.

Мне кажется эту проблему лучше решать на уровне IDE. Ну, например, делаем некоторое средство, которое формирует список экспортируемых сущностей, так, чтобы методом перетаскивания можно было вставить в программу (с автоматическим изменением списка импорта в модуле). Соответственно запрещенные к экспорту модули - недоступны.
Добавляем пункт меню - "Согласовать экспорт/импорт", для поиска модулей у которых список импорта не согласован с "главным" списком. А после наработки практики применения можно будет говорить о "законодательных" мерах.