Ответ на »сообщение 3974« (Илья Ермаков)
___________________________

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

Интересно. Появился повод поработать с BlackBox. :)

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

IMHO, если обобщить, то трудно "приживается" именно понятие модуля.

А такой ли модуль Оберона уникальный, что его устройство непонятно? Может, пояснять на примере чего-то известного, например, модулей Delphi?

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

Ответ на »сообщение 3969« (Илья Ермаков)
___________________________
Полезная вещь. Можно ли иметь несколько складок (скажем, 3-4 варианта интерфейса)? Можно ли на складки отображать разные документы (интерфейсы могут лежать порознь)?

Нет, таких "наворотов" сейчас нет. Вообще, складки - это просто элемент управления содержимым текстового документа. Они используются и в документации, и в различных списках, ну и уже "побочно" приспособлены для манипулирования кодом. Самый простой вариант - компактная свертка закомментированных кусков. Говорят, что они были уже в Обероне Ви4, но я с "классикой", увы, не работал, не знаю.

Как работать с ними в пакетном режиме (в смысле направлять компилятор на нужные сейчас интерфейсы для группы модулей)?
Ну, пользуясь тем, что Блэкбокс - сам себе скрипт, можно дописывать какие-то сценарии для этих вещей. Например, один мой коллега большой их любитель. Он вообще использует вкладки в стиле современных редакторов кода - для сворачивания больших кусков кода. А на пункт меню "Компиляция" повесил три команды "Развернуть свернутый код"; "Откомпилировать"; "Завернуть обратно".

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

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

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

Ответ на »сообщение 3969« (Илья Ермаков)
___________________________

Да фолды - это особые отображения в составных документах Блэкбокса. "Складки". Скалдка содержит два варианта текста - "сворачиваемый" и "лицевой" (хотя никакой разницы в их ролях нет).

Полезная вещь. Можно ли иметь несколько складок (скажем, 3-4 варианта интерфейса)? Можно ли на складки отображать разные документы (интерфейсы могут лежать порознь)? Как отличить разные складки друг от друга (содержимое почти одинаковое, на глаз с ходу не поймешь)?
Как работать с ними в пакетном режиме (в смысле направлять компилятор на нужные сейчас интерфейсы для группы модулей)?

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

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

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

Я предложил ASU назвать язык/решение, который удовлетворял бы его запросам (на чем-то и как-то он решает озвученные проблемы, с которыми и сопоставляет видимо Оберон). В ответ -- тишина. Домысливать за других -- не самое благородное занятие.

Вообще все это выглядело весьма странно. Как можно понять, что импортируется модуль (все его содержимое), если известно, что модуль в Обероне (по определению) регулирует область видимости исключительно через экспорт-импорт. Импортировать можно только то, что экспортировано. А весь экспорт заключен в интерфейсе. Как тут что-то можно было напутать? От незнания, что такое модуль? Т.е. мы тут несколько лет это обсуждаем, а отнюдь не посторонним это невдомек?

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

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

>>>Пардон за мою дремучесть, а что есть фолды? Каталоги что ли? Если так, то как насчет рассогласования версий модуля?

"Фолды" -- это "складки".
Кусок (программного) текста может быть упрятан в складку и снова извлечен оттуда.
В целях управления этим процессом, складки могут помечаться специальными именами.
Тогда можно давать команды вроде: "спрятать/показать содержимое складок, помеченных словом Debug".
Содержимое спрятанной складки не компилируется.
Короче, складки -- один из механизмов управления текстом программы.

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

Ответ на »сообщение 3961« (Mirage)
___________________________
Пардон за мою дремучесть, а что есть фолды? Каталоги что ли? Если так, то как насчет рассогласования версий модуля?

Да фолды - это особые отображения в составных документах Блэкбокса. "Складки". Скалдка содержит два варианта текста - "сворачиваемый" и "лицевой" (хотя никакой разницы в их ролях нет). Шелкаем по стрелочке складки - варианты текста меняются местами. В Блэкбоксе они используются много для чего, и в частности - как своего рода "условная компиляция". Легко переключать нужные варианты кода. Кроме текста, вкладка имеет имя. Несколько вкладок в тексте могут иметь одно имя. Тогда их можно переключать массово командами StdFolds.CollapseLabel/ExpandLabel.
Например, перключение между отладочным и релизным режимом можно осуществлять парой команд
StdFolds.CollapseLabel DEBUG / StdFolds.ExpandLabel DEBUG.

Не так уж плохо иногда отвлечься от деталей и посмотреть на общую, панорамную картину.
Примерно такую встряску устроил нам ASU, и полагаю, что из этого можно извлечь некоторую пользу.
Выяснилось, что о самых простых (фундаментальных) предметах мы думаем (или, по крайней мере, говорим) по-разному.
Возможно, теперь, когда это открылось, нам удастся достичь большего взаимопонимания, чем прежде, когда мы думали, что расхождения только в частностях "профессионального" характера.
Александр Сергеевич (ASU) полагает, что квалифицирующий импорт противоречит "слабости" межмодульных связей. Какие, мол, "слабые" связи, если явно указано имя модуля.
Это интересная точка зрения, попробуем разобраться с ней получше.
Сергей Перовский высказал предположение, что за этой точкой зрения стоит не только абстрактная теория систем, но и некоторая программная реальность, например технология COM. Возможно, это и так, хотя я скорее усматриваю тут влияние UNIX: отдельные программы-модули работают как фильтры, а в целое (систему) они соединяются с помощью командных скриптов оболочки. В общем, у каждого могут быть здесь свои фантазии. :)
Попробуем рассмотреть аргумент Александра Сергеевича по существу.
Обероновскому подходу (с квалифицирующим импортом) он противопоставляет некие непривязанные к модулям интерфейсы. Сразу возникает вопрос чьи это интерфейсы? (Сам ASU спросил бы -- между чем/кем эти интерфейсы?)
По-моему, это пока неясно.
Второй вопрос: как должен решаться конфликт имен? Или программист должен отслеживать все имена в системе, чтобы избежать ошибок?
Во всех языках, рассчитанных на создание крупных программных систем, для решения этой проблемы были введены специальные механизмы. В тех языках, где нет явных модулей, были введены пространства имен (например, в C++ и C#). Но ASU не говорит ни слова об этих мезанизмах.
У меня также создалось впечатление (вероятно, ошибочное), что ASU отрицает иерархическое устройство систем (это было бы очень странно). Мол, части системы взаимодействуют, ничего не зная друг о друге, без всякого иерархического соподчинения. Да, такое может быть, но только если о взаимодействии этих двух несведующих частей системы позаботилась третья, более осведомленная.
Саму же мысль, что квалифицирующий импорт как-то вредит "слабым" связям, я считаю следствием неосведомленности о том, как используются в Обероне модули.
Кроме прочих задач, модуль в Обероне может исполнять роль коммутатора. Это очень простая вещь, о которой имеет представление всякий, кто знает, что такое процедурная переменная (указатель на функцию в Си) и указатель на объект. Поэтому клиент не привязан жестко к какой-то конкретной реализации функциональности.
Именно наличие выделенного разъема (точки коммутации) позволяет в Обероне легко менять на лету реализацию той или иной функциональности. Поэтому квалифицирующий импорт не противоречит "слабым" связям, а напротив, является одним из механизмов их поддержки.
Поэтому я считаю, что сам вопрос, поднятый ASU, возник вследствие недоразумения, но обсуждение этого вопроса вполне может оказаться полезным, устраняя подобные недоразумения.

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

А разве нельзя сделать так, как например в Хаскелле: создаётся новый модуль под другим именем (раз всё равно интерфейс по сути другой, логично и имя ему дать другое), и он импортирует основной модуль и реэкспортирует некоторые сущности из него...

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