OberonCore

У меня ещё в прошлый раз родился вопрос: зачем они для установки значения переменной trap пользуются метапрограммированием? Ведь проще без него.
Например:
Или я чего-то не учитываю?

Когда будем, тогда лучше и подумаем.А пока Вы же можете сделать стандартную (для себя) библиотечку для КП. Может для других платформ она (по интерфейсу) и подойдёт.

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

В общем, палка о двух концах...

В более ранних исходниках так и сделано, а потом добавили такую фичу. А так я согласен, что перед секцией FINALLY написать trap := FALSE; ничего не стоит... Кто то наверное забыл написать trap := FALSE; пару дней на поиски потратил и сделал так, как есть сейчас

может какие доп мысли будут:
http://www.intuit.ru/department/se/oopbases/12/
http://oberon2005.ru/paper/m2ex.pdf

Опять с характерной занудной претензии начинается...
Вирт же ясно говорит: он включает в свои определения только то, про что есть полная уверенность, что это "то" необходимо и как "его" устроить, чтобы не сломать шею.

Каждому предоставляется право экспериментировать на свой страх и риск.

Ещё немного информации к размышлению.
Здесь предлагалось в качестве возможного подхода к освобождению внешних ресурсов использовать FINALIZE: то ли дождаться, когда Kernel.Collect сам сработает, то ли вызвать Kernel.Collect явно.
Такой подход кажется мне неудовлетворительным (независимо от синтаксического/библиотечного оформления) по ряду причин, главная из которых - традиционно консервативная сборка мусора в Оберонах (применительно к указателям, размещенным в стеке). Это означает, что при нахождении в стеке переменной, чьё значение случайно совпадает побитово со значением указателя, объект не будет освобождён (даже если на него не указывает ни один настоящий указатель). Т.е. освобождение внешнего ресурса с помощью (форсированной) сборки мусора не гарантировано.

Ещё есть:

(видимо, дело будущего - указатели фтопку и автопамять без сборки мусора... Пути к тому вроде видны.)

Это почему еще? Компилятору доступна вся информация о каждой процедуре, где у ней указатели в процедурном фрейме, где прочие данные.

Однако она не используется.
В известных реализациях (классический Оберон, ББ; АктивОберонСистем - насколько я смотрел 2 года назад) - просто пробег по стеку.

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

Т.е. совсем не будет исключений?
Как же на такой платформе бороться с разыменованием нулевых указателей, выходом за пределы массива и т.п.?

Не пойму, речь-то о чем: о "в принципе" или "в конкретной реализации"?

Прежде всего, я хотел предупредить, что при разработке надёжного приложения в ББ не следует (слишком) полагаться на FINALIZE.
Что касается особенности "конкретной реализации", то создаётся впечатление, что это особенность всех известных реализаций Оберона. Возможно, консервативный подход к стеку вызван желанием повысить скорость сборки мусора.
Конечно, в принципе в Обероне возможна точная сборка мусора. Но по практическим соображениям (скажем, во встроенном приложении) может быть отдано предпочтение (полностью) консервативной сборке. Так что финализаторы остаются под вопросом.

Это как - всё время выделять новые страницы памяти?
Насчёт указателей (пока) не очень понятно: ведь без них (явно или скрыто) не получится работать с динамическими структурами данных.

Горячится молодежь.
Главное -- не покупаться

Про новые страницы - ну, такая идея используется на платформах со 128-бит указателями (типа IBM AS/400 или "Эльбрусов"). Выделяемые виртуальные адреса не повторяются - поэтому повисший указатель всегда обнаружим. Я делал такую штуку и в малом адресном пространстве, с доп. косвенной таблицей. Правда, эти способы гарантируют безопасность, но не дают функциональности "якоря" (т.е. чтобы объект жил, пока кому-то нужен).

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

Вот пока всё, что я могу сказать по поводу "пути вроде видны".

... и остаётся открытым вопрос, как лучше освобождать внешние ресурсы.
Евгений Темиргалеев рекомендует PROCEDURE InstallCleaner (p: Command) (она определена в модуле Kernel).
Я сейчас использую вызов через процедуру Kernel.Try, гарантирующую перехват исключения.
Какие ещё могут быть подходы?