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

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

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

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

Ответ на »сообщение 4339« (Руслан Богатырев)
___________________________
>>>А здесь пояснял своему оппоненту, что негоже требовать от языка программирования того, что нужно языку совсем иного назначения.
Было очень забавно наблюдать Ваш спор с ASU, т.к. исходя из одних и тех же предпосылок (правда изложенных в очень разной манере) вы приходили к противоположным взгладам на межмодульное взаимодействие. И я склонен принять его сторону: какой модуль должен реализовывать тот или иной интерфейс в конкретной системе, должно описываться в языке конструирования системы, а не в языке программирования.
Мне ближе восприятие модуля (раз уж речь идет о модулях загрузки), как сервера и клиента в одном лице. Чтобы собрать систему, необходимы модули, решающие конкретные задачи и все модули, предоставляющие необходимые для этого услуги. Язык конструирования системы должен позволить назначить конкретный модуль на роль поставщика конкретной услуги (функции, переменной, типа данных) и контролировать замкнутость системы.

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

Например, "посмертный" отладчик в ББ вызывается именно в момент исключения (которое может также явно "выбрасываться" через HALT и ASSERT) и позволяет просматривать значение всех переменных в стеке на момент прерывания программы (опять-таки метапрограммные механизмы).

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

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

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

Ответ на »сообщение 4340« (Руслан Богатырев)
___________________________

То, что я здесь описал -- принципиально иная идея. На уровне исходного текста на Обероне кроме ASSERT вообще ничего нет. Реакция вынесена не просто за пределы языка программирования, а за исходные тексты Оберон-модулей! А это дает весьма интересное следствие -- при обработке исключений обработчик не может оперировать сущностями языка, в котором возникло исключение!

Кажется, все же не совсем так.
Например, "посмертный" отладчик в ББ вызывается именно в момент исключения (которое может также явно "выбрасываться" через HALT и ASSERT) и позволяет просматривать значение всех переменных в стеке на момент прерывания программы (опять-таки метапрограммные механизмы).
Конечно, явный минус ASSERT-а в том, что он не может передать в обработчик данных об исключительной ситуации, в отличие от специальной (расширяемой) записи Exception в статье Мессенбека.
Но "механика", в принципе, одна и та же.

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

Важно отделить "внутренние" модули кластера от "фасадных".

Да, это важно. Тут могут быть разные варианты. Если "протаивать" языки, то язык кластеров может предоставлять компилятору Оберона необходимую хинтовку (напр., какие интерфейсы тому или иному Оберон-модулю можно импортировать, а какие -- нет).

Возможно, для этого достаточно добавить во внутренние модули секцию EXPORT (по аналогии с секцией IMPORT).

Не стоит ничего трогать в языке Оберон/КП. Это можно сделать этажом выше, на уровне иного языка.

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

>>>Нет, просто обработка исключений достаточно громоздкая штука, заметно усложняющая язык и компилятор.

Давно известен способ обработки исключений, совершенно незатрагивающий компилятор:

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

Результаты нашей группы изложены здесь: http://www.europrog.ru/paper/m2ex.pdf
Мы также исходили из выноса исключений на уровень библиотек (как и австрийская группа Мессенбека). Также использовался ран-тайм.  В этом принципиальной разницы нет. Другое дело, что мы предусматривали еще исключения для асинхронных (параллельных) процессов, т.е. разделяли на внутренние и внешние плюс обеспечивали более тонкую реакцию, но это уже приятные мелочи.

Наша работа была завершена (в смысле работала реализация для Модулы-2) в середине 1991 г. Подготовлена публикация на англ. в апреле 1992 г. и передана Гюнтеру Дотцелю (Modulaware). Он опубликовал ее в своем самиздатовском журнале ModulaTor: http://www.modulaware.com/mdlt22.htm

Самиздат не накладывал ограничений на публикацию в приличных печатных изданиях и по совету Дотцеля я направил ее в журнал “Structured Programming” (Springer-Verlag, в редколлегии – Д.Кнут и Н.Вирт). После двух кругов работы анонимных рецензентов статью признали достойной (готовилась к печати почти год). Это была, если не ошибаюсь, первая публикация советских авторов в таком престижном издании: http://www.informatik.uni-trier.de/~ley/db/journals/stp/index.html

То, что я здесь описал -- принципиально иная идея. На уровне исходного текста на Обероне кроме ASSERT вообще ничего нет. Реакция вынесена не просто за пределы языка программирования, а за исходные тексты Оберон-модулей! А это дает весьма интересное следствие -- при обработке исключений обработчик не может оперировать сущностями языка, в котором возникло исключение!

Ответ на »сообщение 4337« (Сергей Перовский)
___________________________

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

Сергей, я к этому пришел примерно лет 20 назад. Кое-что было опубликовано в трудах конференции "Методы трансляции и конструирования программ" (Новосибирск, 1988 г.). А здесь пояснял своему оппоненту, что негоже требовать от языка программирования того, что нужно языку совсем иного назначения. О каких большевиках Вы толкуете? Быть может, что-то упустил. Если нетрудно -- дайте ссылочку.

Необходимость обработки исключений из этой же серии. Вирт не знал об этой проблеме? Или доказал достаточность ASSERT?

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

Ответ на »сообщение 4337« (Сергей Перовский)
___________________________

Сначала лозунг - модули и ничего кроме модулей, потом введение понятия кластера.
Сначала лозунг о достаточности одного имени для модуля и его интерфейса, потом объединение модулей в кластер с совершенно другой конструкцией интерфейса совершенно отдельного от модулей.

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

>>>Нет, просто обработка исключений достаточно громоздкая штука, заметно усложняющая язык и компилятор.

Давно известен способ обработки исключений, совершенно незатрагивающий компилятор:
http://www.oberon2005.ru/paper/p_ex.pdf

Ответ на »сообщение 4330« (Руслан Богатырев)
___________________________
>>>Подобные размышления наталкивают на мысль о выведении средств управления кластерами в отдельный язык (именно язык), в большей степени декларативного характера, который описывает "топологию", инварианты, отношения, состояния.
Ну вот, Вы и пришли к необходимости разделить язык программирования и язык конструирования систем, о чем много дней "говорили большевики".
Сначала лозунг - модули и ничего кроме модулей, потом введение понятия кластера.
Сначала лозунг о достаточности одного имени для модуля и его интерфейса, потом объединение модулей в кластер с совершенно другой конструкцией интерфейса совершенно отдельного от модулей.
Лозунги вообще плохо реализуемы, так как упрощают действительность до полного примитивизма.
Необходимость обработки исключений из этой же серии. Вирт не знал об этой проблеме? Или доказал достаточность ASSERT? Нет, просто обработка исключений достаточно громоздкая штука, заметно усложняющая язык и компилятор. А то, что она необходима, люди поймут только при достижении определенного порога сложности программ.