OberonCore

Нет документации на модули Kernel, Windows, Sequencers, Mechanisms, Documents
Кто с ними работал, как их можно использовать?

И почему Kernel не находится в Host? Это тоже непереносимый модуль реализации (использует WinApi).

Документация на Кернел (местного производства) есть в комплекте с АББ, если я не ошибаюсь.

И, кстати, Кренел достаточно переносим...

Нутро Kernel на 60% переносимо.
Интерфейс же этого модуля вообще полностью платформенно независим. В частности, может использоваться для низкоуровневого метапрограммирования.
Я составил полную документацию на ядро, она есть в пакете Активного Блэкбокса.

А зачем с ними работать?
Зачем увеличивать объем связей между модулями (своими и внутренними модулями системы)?

Просто так -- плохая идея.

Чувствую, что в "законе насыщения степеней свободы языков программирования" нужно добавить "и библиотек".

А вы уверены, что эти модули внутренние? Вот Log тоже недокументирован...

Ну так и разделили бы на Kernel(60%) и HostKernel(40%).

Вроде как интерфейсы многих модулей из Host тоже платформенно независимы...

Интересно, почитаю...

Этим и занимаюсь. В релизе Активного ББ ядро будет порезано на ряд микроядер.

Нет, понимаете, здесь штука какая: подсистема Host - это подсистема, не предназначенная для импорта ВООБЩЕ. Это модули реализации под соотв. лицевые интерфейсные модули каркаса. Все. Посмотрите сетку связей через DevDependencies, Вы увидите, что Host в ББ не импортируется никакими другими подсистемами.
Kernel - это системный интерфейс ББ, но - интерфейс, который можно импортировать и использовать и который не изменится в очередных версиях. Kernel импортируется даже в достаточно высокоуровневых местах каркаса, где требуется сквозное метапрограммирование (например, информация о локальных переменных или сигнатурах процедурах). Модуль Meta поддерживает только защищенное метапрограммирование, т.е. работу с интерфейсными частями модулей.

Если посмотреть внимательно, то импортируется.

Руки бы поотбивать... :):)

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

Так модули Host сами друг друга внутри подсистемы импортируют!
К сожалению, в настоящий момент нет надъязыковых средств, которые могли бы разграничить внутренние интерфейсы подсистемы от внешнего ее интерфейса - о полезности создания таких средств много говорил Руслан Богатырев на Королевстве.
Ну и плюс, конечно, Host иногда является той "форточкой", которая позволяет в горячечном бреду хронического неуспевания по конкретному заказу быстро реализовать какую-то фичу С растровой графикой через WinApi, например - пока что в ББ нет платформенно-независимого интерфейса работы с растром.

А хватит ли надъязыковых средств, что-то сомневаюсь...

Тонкий вопрос. На Королевстве кое-что обсуждалось месяц назад по этому поводу. Одно ясно - реальные подвижки в этом направлении будут только при конкретной необходимости, и ничего в самом языке не мешает достраивать контроль верхнего уровня за межкомпонентными интерфейсами и т.п.

И можно запретить импортировать внутренние модули какой-нибудь подсистемы?

На надъязыковом уровне - а почему нет?
Дополнительные внешние спецификации на границы подсистем + компилятор, умеющий учитывать эти спецификации и на попытку импорта внутреннего модуля какой-то подсистемы говорящий "not found". Или представьте себе, что у каждой подсистемы есть две папки под Sym-файлы: Sym - для внутреннего пользования, а FaceSym, к примеру, - для наружного. И при компиляции некоторого модуля доступны только Face-спецификации других подсистем - и все спецификации его родной подсистемы.

А не придётся язык модифицировать для соответствующих объявлений видимости?, Типа "**" и "--" ? :о)
Или можно следовать правилу Кернигана "Проблемы с изъяснением? - вводите ещё один уровень косвенности!" :о) В смысле, кроме договорённости про первое слово в объявлении модуля, как имени подсистемы, нужно ещё будет вводить и "модуль доступных объявлений подсистемы" и договрариваться, что его имя будет таким же, как имя подсистемы (например!), типа:

MODULE SubsystemSubsystem;
...
А тут (пере)объявляем чего "за пределами" подсистемы "видно".
...
END SubsystemSubsystem.

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

Вы, ребята, чё-то не то замышляете...

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

Дык ведь вопрос поднят! И он, как мне кажется, назрел и правомерен!
Про область видимости в виде "модуля" подумали, а что делать с реализацией отношений на уровне выше - на уровне подсистем?
Ведь и правда, почему не подумали об ограничениях видимости В РАМКАХ СОВОКУПНОСТИ МОДУЛЕЙ (как-то специфицированной и формально объявлённой) ?
Так шо, если мы не хотим уходить за пределы языка ПРИДЁТСЯ вводить соглашение по именованию "модуля выразителя-представителя" подсистемы для клиентов подсистемы...

Просто не распространяйте исходных кодов и символьных файлов приватных модулей своей подсистемы. Тогда их ни кто и не сможет импортировать.

Минимальная модификация компилятора: стирать "избранные" символьные файлы сразу после компиляции подсистемы.