OberonCore

Вот именно. Безопасность среды выполнения и инварианты относительно целостности памяти нигде не нарушаются.

Тогда зачем в контексте "герметичной системы типов" часто упоминается жёсткая модулбность и сокрытие данных как один из главных компонентов этой самой герметичности?

А где эта модульность и контроль нарушены?
Если разработчик модуля не открыл Вам доступ тем или иным способ (экспортом всего типа или указателя на него - для доступа на этапе компиляции, экспортом поля - для доступа через метапрограммирование), то Вы никаким легальным путём (кроме выхода на уровень IMPORT SYSTEM) доступа к внутренностям модуля не получите.

Все же герметичность (info21) системы типов и сокрытие данных - разные вещи.
Герметичность обеспечивается языком (если явно не прибегать к loop-holes) независимо от модульности. Независимо от того, есть в Обероне модули или нет, язык гарантирует type-safety. Все ошибки такого рода будут обнаружены либо во время компиляции, либо во время выполнения программы.

BTW, любопытно, что обероны зачастую не заморачиваются поиском некоторых второстепенных ошибок во время компиляции, полностью полагаясь на надежность проверок во время выполнения программы или ошибку компиляции в другом месте. Примером первого может быть следующий цикл: Примером второго - недавно обсуждавшееся в Дельфином Королевстве объявление процедуры При требовании поименного (за исключением процедурных типов) совпадения типов формального и фактического параметров, такая процедура не может быть вызвана, но... компилятор молчит, предвкушая момент, когды вы попробуете-таки вызвать эту процедуру.

Итак, инварианты памяти (type-safety) гарантируются языком независимо от наличия в нем модулей.
Модульность и, соответственно, сокрытие данных помогают программисту обеспечить выполнение введенных им инвариантов, т.е. защищают только программистские инварианты (что, конечно, невозможно без type-safety, в т.ч. межмодульной).

Прошу обратить внимание: модули в Обероне именно позволяют расширять возможности языка и вводить новые понятия. Такая цель введения модулей в язык программирования явно декларировалась Виртом еще с середины 1970-х.
В Preface к известной нам всем книге Programming in Oberon (2004) Вирт пишет:Я специально выделил утверждение, что такие базовые понятия как файл и текст в Обероне вводятся в форме модулей.
Поэтому я просто не понимаю вздохов Зуева о "низкоуровневости" Оберона.

Интересно: оформление форума меняется... то одно, то другое... экспериментируем?

Уже несколько недель не прикасаюсь к настройкам вообще.

Я тоже. Моя гипотеза -- Женя не слишком хорошо понимает Оберон.

Похоже, вид форума меняется в зависимости от того, вошел ли я как зарегистрированный пользователь или присутствую как гость?

вообще-то можно. а некоторые до сих пор считают что и нужно))
напоминаю малоизвестную деталь. первые Обероны изначально проектировались
с раздельными файлами интерфейса и реализации, как Модула-2.
Склейка и введение броузера были потом - как усовершенствование, ревизия.
Однако ulm-оберон например до сих пор как мне известно имеет
отдельные файлы интерфейса и реализации и неплохо себя при этом
чуствует)) и продолжает развиваться в своем особенном направлении
до сих пор)) Его авторы _сознательно_ не стали эту часть ревизии
в свое время принимать поскольку посчитали старый вариант более выгодным
для себя... по-моему есть и другие (менее известные) системы
с первоначалным вариантом...

Вот никак че-то не пойму: зачем это нужно?
Можно же отдать sym-файл вместо интерфейса?
Компилятору sym-файл только и нужен?
Заранее спасибо тому, кто растолкует.

Да. Меняется состав, индивидуальные настройки и темы, если у вас в настройках стоит ProSilver (основным идёт SubSilver2).

Хм. Что-то мы тут ветку портим...

попробую растолковать по аналогии...
зачем распространять исходник программы когда можно обьектник?))
а потому что исходник принципиально более информативен и гибок...
и дело не только в комментариях...
На решение Вирта видимо повлияли два фактора.
1) поначалу часто приходилось менять архитектуру, экспериментировать.
2) не было необходимости определять интерфейс с окружающим миром
и другими языками, все было полностью на Обероне. собственно никакого
окружающего мира и не было))

...вроде еще в XDS и oo2c definition остались...

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

Аналогия не проходит: sym-файл читается в человеческом виде -- вся информация дадена.

Наличие отдельных def-файлов несколько способствует стабилизации интерфейсов.
Кстати, в ETH-Obeon компилятор по умолчанию не изменяет sym-файл, а только проверяет и ругаецца. Чтобы разрешить компилятору переписать sym-файл, надо вызвать его с соответствующей опцией.
Хотя, никаких sym-файлов там нету.

несмотря на то что Сим может быть конвертирован в читабельный вид, в нем
хранится НЕ ВСЯ информация из Деф... Любая компиляция по определению есть частичное вычисление а при любом вычислении генерируется некоторая новая информация на основе ПОДМНОЖЕСТВА входной информации. Тупой пример - форматирование Деф для читабельности или структуризующий порядок определений - теряются в принципе. Кроме того даже если была вовлечена
вся информация, обратить вычисления не всегда возможно.
Далее, если есть Деф его возможно еще дополнительно нагрузить потом если потребуется. А с Сим это не пройдет, формат строгий нужен.

Но главное, КАК Я КОНКРЕТНО СКАЗАЛ, Сим генерируется из реализации но ведь реализации вообще может и не быть в принципе!)) пример - FOREIGN definition... Это когда реализация НЕ на Обероне. Поэтому выбрасывание Деф с заменой его на Сим возможно не всегда а как минимум лишь внутри Оберон-системы только.
А раз так - в ЯЗЫКЕ этого делать не следует.
Разве что можно добавить такую фичу в реализацию. Имхо конечно.

ЗЫ. что компилятор по умолчанию без указания спецключа не меняет Сим я конечно знаю)). Но результата это почти не меняет)).
Указать ключ по ошибке гораздо проще (по умолчанию они рядом в меню) чем ошибочно внести длинные осмысленные модификации в Деф (на нестыковки тут же заматюгается компилятор).
Плюс в оберонах сейчас чаще идет расширяемый Сим файл, который вообще допускает определенные модификации интерфейса модуля БЕЗ всяких ключей, лишь выдает сообщение типа "добавлен новый символ, горячо поздравляю"
и далее расширяет Сим...
И все это идет как положительная ( )) ) удобная фича.
Возможно. ИНОГДА. Когда исходники коммерчески закрыты, больше никак.
И ведь добавления не всегда настолько безопасны как кажется на первый взгляд...

Ну и само собой то что в систем3 Сим слит с обьектником, еще дальше сокращает информацию о структуре и ПУТИ развития системы.
и почти устраняет возможность наличия нескольких (или внешних)
реализаций... Обероны - это специализированные СИСТЕМЫ-В-СЕБЕ.
В изоляции и сила их и слабость. Их подход - все или ничего.
Не модификация а перепроектирование. Это иногда хорошо а иногда плохо.

Если в модуле переименовать какой-нибудь параметр у экспортируемой процедуры и перекомпилировать, а потом просмотреть интерфейс этого модуля, то будет показано старое имя параметра Баг?

Да, знаю эту вещь... По-моему, компилятор видит, что фингерпринты всех сущностей неизменны, делает вывод, что интерфейс модуля тоже неизменен, и не переписывает символьный файл. Беды в этом никакой нет, но может вогнать в ступор... Я долго допетривал, в чём дело. Потом изменил тип параметра туда-сюда - и переписал символьник.

Интересно, знают ли об этом в OM? Все-таки, если в символьном файле хранятся имена параметров, то делать это надо корректно. Вдруг кому-нибудь захочется поменять местами два однотипных параметра...

Сообщили бы им У Вас уже один баг-репорт с баг-фиксом уже был, продолжайте традицию