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

Фолды в среде или директивы компилятору (раз уж говорили тут о препроцессоре) изящно (это про фолды :) ) решают проблему.

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

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

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

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

>>>А интерфейс может быть ТОЛЬКО абстрактным. Синтаксический минимализм, это конечно приятно, но считать интерфейс частным случаем модуля все таки не стоит.

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

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

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

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

Но отличие Хаскелла от Оберона тут в том, что никаких звёздочек нет, а просто в списке экспорта перечисляется набор экспортируемых сущностей.

И не надо никаких фолдов(?) или директив препроцессора...

Ответ на »сообщение 3952« (Как слышно? Приём!)
___________________________
>>>Вместо обсуждения предложения создать легкий вьюер составных обероновских
документов
Инициатива наказуема :)
Что там обсуждать - делайте, никто не возражает.
Если люди приходят на базарную площадь, значит у них есть идеи или сомнения, которые хочется обсудить. И пользу они от этого обсуждения получают.
У Райкина когда-то была такая миниатюра:"22 бугая мячик пинают - им нужно лопаты выдать и поставить яму копать".

Ответ на »сообщение 3954« (Mirage)
___________________________
>>>Модуль может быть абстрактным (как и класс) и не содержать никакой реализации.
А интерфейс может быть ТОЛЬКО абстрактным. Синтаксический минимализм, это конечно приятно, но считать интерфейс частным случаем модуля все таки не стоит.
Иначе получается, то что получается: сначала декларируется явное указание модуля, из которого импортируется сущность, а потом выясняется, что на самом деле это имя интерфейса.
Та же история, что и с объектами: как отдельный раздел типов данных объекты синтаксически не выделяются, но предоставляются все механизмы реализации.

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

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

Фолды в среде или директивы компилятору (раз уж говорили тут о препроцессоре) изящно (это про фолды :) ) решают проблему.

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

Вдогонку предыдущему сообщению. В языке Modula-3 одной реализации модуля на уровне языка может соответствовать несколько интерфейсов. Сколь часто требуется в практике подобная особенность? Ее ведь можно ввести в Оберон/КП, практически не нарушая язык.

К вопросу об интерфейсах.

При переходе от Модулы-2 к Оберону произошла свертка и смена полярности: DEFINITION-модуль стал производным от MODULE, в котором программист отмечает явным образом (значками экспорта) "протаиваемые" наружу сущности. Поскольку одной реализации (MODULE) соответствует один интерфейс (DEFINITON), то нет смысла давать им разные имена. Говоря "импортируем модуль", мы всегда подразумеваем "импортируем интерфейс" с тем же именем. Именно это, скорее всего, и ввело в заблуждение некоторых участников дискуссии. С другой стороны, трудно себе представить, как можно импортировать то, что не экспортировано, а то, что экспортировано, всегда лежит в интерфейсе (оно и только оно).

Чтобы не было терминологической путаницы, будем считать, что объявлением (declaration) называется полноценное определение сущности, а описанием (definition) -- частичный вариант объявления (в экспортном исполнении). Описания могут быть представлены только в описательных модулях (DEFINITION). В языке Модула-2 DEFINITION-модуль содержал как объявления, так и описания. При этом объявление, сделанное в нем, автоматически было доступно в IMPLEMENTATION-модуле (не требовался "внутренний импорт"). Описание часто использовалось для т.н. скрытых типов (обычно, ссылочных типов), а также для всех без исключения процедур (тела их не могут фигурировать в интерфейсе). В Модуле-2 на уровне IMPLEMENTATION-модулей допускался циклический импорт (поскольку импортировались интерфейсы), тогда как на уровне DEFINITION-модулей цикличность запрещалась. При переходе в Обероне к иной схеме (отказу от явного, "рукотворного" DEFINITION) эти проблемы ушли, а разница между объявлением и описанием многими вообще перестала ощущаться (хотя она сохранилась). Однако, не все так замечательно.

Рассмотрим типичную ситуацию. У нас есть некий модуль M, который находится в стадии доводки. При этом этот модуль экспортирует как доступные клиентам сущности, так и имеет в дополнение к "парадному подъезду" еще и "служебный вход" (например, для целей специальной трассировки). Необходимо сохранять служебные сущности, но при этом время от времени закрывать к ним доступ другим клиентам. В Модуле-2 для этого можно было иметь два интерфейса (в разных файлах -- расширенный и обычный), которые подменялись на уровне конфигурирования системы программирования (напр., в файле проекта). В IMPLEMENTATION-модуле при этом никаких манипуляций делать не надо (только перетранслировать его и всю цепочку зависимости по импорту). В Обероне, строго говоря, надо для этого заниматься перемаркировкой экспорта (то ставим звездочки, то убираем). Не здорово.

Еще о двойственности интерфейсов. Если взглянуть на правила синтаксиса классического Оберона,

ImportList = IMPORT import {"," import} ";" .
Import = ident [":=" ident].

то можно заметить, что теоретически допускается использование объявлений вида

IMPORT A := Str, B := Str;
IMPORT A, B := Str;
IMPORT Str, A, B := Str;

Как я заметил по описанию КП, тот же самый синтаксис используется и в КП. Т.е. можно ставить в соответствие одному физическому имени (справа) интерфейса два логических (слева), причем даже совпадающие с физическим. Одному логическому имени (группе логических имен) ставить в соответствие группу физических имен нельзя. Насколько это поддерживается теми или иными системами программирования Оберонов/КП, надо проверять. Но теоретически такая возможность в язык заложена.

К каким последствиям это может привести?
1. Есть возможность "разрезать" интерфейс в контексте данного модуля-клиента на несколько логических частей. Это позволяет "маркировать" внешние сущности по каким-то признакам (например, процедуры -– по функциональному назначению).
2. Использование в левой части оператора "именной коммутации" физического имени, отличного от значения в правой части, следует рассматривать как  недопустимую практику (желательно, чтобы контролировалась компилятором, если тот может определить наличие интерфейса в своей зоне ответственности).
3. Использование в левой части физического имени, совпадающего с именем в правой части, допустимо. Может быть полезно в качестве "маркировки", при выделении сущностей (скорее всего, процедур и переменных), прошедших тот или иной контроль (физическое имя), от еще не прошедших (логическое имя).
4. Теоретически возникает коллизия: если используется одна и та же сущность в одном модуле-клиенте под разными имена, например, A.Size и B.Size. Если рассматривать это как механизм синонимизации (как обосновывается это в описаниях обоих языков), то коллизии быть не должно -- такое использование допустимо. С другой стороны, может возникнуть иная коллизия -- смысловая (для программиста), поскольку одна и та же внешняя сущность называется по-разному.

О реализациях. Можно ли к одному интерфейсу (DEFINITION) иметь несколько альтернативных реализаций? Да, можно. Это находится в сфере компетентности конфигурирования системы программирования (а также загрузчика).

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

Ответ на »сообщение 3952« (Как слышно? Приём!)
___________________________

Ответ на »сообщение 3947« (Владимир Лось)
___________________________
То есть прикажете терпеть словоблудие?
В Обероне как раз технологий то маловато. Всё больше рукоделие предлагается.
Вместо обсуждения предложения создать легкий вьюер составных обероновских
документов, например, или развить инструментальную панель ББ для облегчения
создания интерфейсов, о чём плачет вся молодёжь на сайте metasystem,
что мы лицезреем?

Готовим. И вьювер, и кое-что еще. Скоро будет новый Service-Pack. И новый школьный пакет. И новый ABF. Скоро, уже почти в прокате :-)