Ответ на »сообщение 3921« (Илья Ермаков)
___________________________
Да, можно контролировать на соответствие интерфейсу, а не другому модулю. Т.е. интерфейсы лежат отдельно, в особых "пакетах интерфейсов", и на их основе производится "сверка". В Обероне возможна и часто используется и такая схема, просто отдельного вида "пакета для интерфейсов" не вводится. (курсив мой)...
Вот и получается весьма странная картина... Сначала в язык встраивают «импорт», а потом с ним начинают бороться (и при этом радуются, что бороться оказывается можно...). Так ведь, бороться с импортом можно в любом языке... его имеющем (лично я исключений не знаю).

Используются модули общего вида. Просто интерфейсы выделяются в отдельный, третий модуль, который содержит исключительно секцию описаний. Этот модуль явно импортируется всеми модулями-агентами, взаимодействующими на основе описанных интерфейсов. При этом сами агенты друг друга импортировать уже не обязаны, они никак не связаны между собой, но жестко связаны с единственным описательным модулем - который выполняет роль общего договора, контракта по интерфейсам. Т.е. ваша схема с обособлением описания интерфейса прекрасно воплощается и в Обероне.
Схема не моя... А с «прекрасным воплощением» Вы спешите... сильно спешите... Если не лень, то посмотрите, как «нарастает» логика системы, я об этом писал. Обеспечение нормальной поддержки интерфейсов – это только первый и самый простой шаг... С другой стороны, «дорога в тысячу миль начинается с первого шага»... :)

Просто в Обероне модуль - универсальная "капсула" на все случаи жизни.
Универсальность разная бывает... Молоток универсален им можно забить почти любой гвоздь в почти любую поверхность, но... суп есть им неудобно. Для написания элементов системы Оберон вполне пригоден, а вот для сборки системы... извините...

Что в нее положите - тем и будет. Можно придумывать специализированные конструкции для хранения интерфейсов, но это уже не первая необходимость, и делать это стоит неспеша и осторожно (как, например, в языке Zonnon, являющимся экспериментальным ответвлением Оберон-семейства).
«Можно» придумывать или «нужно» придумывать?..

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

Ах да, возникал вопрос по метапрограммированию. Мы называем метапрограммированием совокупность а) доступа к описаниям языковых сущностей и символьной информации на этапе выполнения программы (рефлексия)
Доступа для кого?.. Это далеко не праздный вопрос, поскольку элементы системы... требуют системного сервиса, а системный сервис должен быть «универсален» и конкретен одновременно. Но вот если это описание на этапе выполнения доступно всем, то...

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

Таким образом, при метапрограммировании язык становится сам для себя скриптовым языком, что ли - как Вы правильно догадались.
Пока я еще не все понял... но тема интересна.

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

Оберон удобен тем, что является своего рода "ассемблером" компонентного программирования, на котором удобно и быстро реализуются любые компонентные механизмы. Но сам язык - это не "пластилин", а набор жестких кубиков. Гибкие связи описываем и отстраиваем уже мы сами. Как захотим, так и построим. А внутри отдельных монолитных блоков (а такие блоки всегда будут. Те же процессоры делаются на одном кристалле, и никакой гибкостью внутри там и не пахнет...) используем предельно простые и понятные явные связи на основе квалифицированного импорта.
Это мы уже обсуждали... Я не схемотехник, но могу Вас заверить, что монолитность она только извне видится, а вот стоит заглянуть внутрь... Системы не имеющие «слабых» связей... это вообще не системы... и это нечто не может развиваться (только ломаться и создаваться заново)... увы...

К вопросу о "пригодности Оберона для системного программирования".
Имелись в виду два аспекта: 1) для системного в том смысле, который я описал. Т.е. для написания ОС, критичных систем реального времени и т.п. Для этого по факту Оберон один из лучших языков сегодня.
Хотелось бы увидеть этот факт...

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

И чем больше работаешь на Обероне, тем больше видишь небольших мелочей, которые при первом взгляде кажутся не особо значимыми, а затем понимаешь, что не будь сделано именно так - и использование того или иного приема/паттерна стало бы гораздо менее удобным.
И изучение команд ассемблера дарит массу приятных моментов... Я по системе команд процессоров Альфа (DEC)... до сих вздыхаю... хотя это RISC, но какой! :)

И еще - под Обероном мы понимаем не только язык, а всю совокупность схем/приемов, апробированных в добром десятке операционных систем и сред этого семейства.
А... ежели так, то... разговор теряет смысл... Таких приемов и средств и у других «системных» языков хватает. Говорить о пристрастиях... не хочу, извините.

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

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

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

Однако давайте без фанатизьму.
Хотя ASU и открещивается от COM технологии, его рассуждениям соответствует прежде всего она. И аргументы кажутся разумными: соответствие между объявленными интерфейсами и реализующими их модулями должны быть известны системе и не могут быть известны использующими модулями. СОМ технология во многом не совершенна, но этот принцип реализован очень здраво. Независимое описание(и наследование) интерфейсов и реализаций, обращение только к интерфейсу, сокрытие не только кода реализации но и имени модуля реализации представляется очень разумным подходом при строительстве сложных систем. Возможность построить модуль для реализации нескольких ранее объявленых интерфейсов тоже заметный плюс.
Вот и давайте сравним Оберон технологию с СОМ технологией.
Возможность объектного интерфейса это, конечно, плюс Оберону, но это скорее недоработки СОМ технологии.

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

>>>Повторяю еще раз... Интерфейс находится между уровнями системы...

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

>>> Линкеры и библиотекари "в свое время" никак указанную задачу не решали.
>> То есть... как это не решали?
> Да так -- не решали и все. :)
Жаль, конечно... У меня решали... у Вас – нет...

Хм... (c) ASU :)
Если брать Си/Си++, то эта задача в них и сейчас не решается.
Иначе попробуйте объяснить наличие стандартного пункта меню (и кнопки тулбара) "Rebuild all".
Зачем это надо, раз все под контролем?

> Если Вас этот вопрос затрудняет, дам подсказку: кнопочки находятся на передней панели телевизора (или его remote control), но никак не человека. :)
Меня эти вопросы ничуть не затрудняют. Если позволите, то дам свой ответ: кнопочки находятся на интерфейсной панели телевизора или плиты. Кнопочка – это не горелка, кнопочка – это приспособление для человека (даже если находится на плите или поставляется с плитой). Попробуйте представить себе кнопку в виде иголки или столь тугую, что нормальный человек ее нажать не сможет. Представили? Хорошо... Надеюсь понятно?

А почему именно человек?
Может быть, у меня хозяйством занимается робот? :)
Все это близко к софистике, Александр Сергеевич.
С системной точки зрения объект низшего уровня именно потому может использоваться в разных контекстах и разными "хозяевами", что (почти) ничего не предполагает об объектах высшего уровня.

http://delphikingdom.com/asp/talktopic.asp?ID=366&ref=msg&msg=2874#msg2874
Попытался поразмыслить на тему построения школьного курса информатики и роли в нем ИП и ФП...

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

Прояснив более-менее ситуацию с претензиями к квалифицирующему импорту, вернемся к подплеке того вопроса. Она раскрылась в »сообщение 3903«:
Моя точка зрения весьма проста, что для создания систем, Оберон не лучше других языков, требующих указания импорта... (даже не важно, квалифицирующего или нет). И позиционирование Оберона, как языка системного программирования, совершенно необоснованно.

Вот, оказывается, что так беспокоило многоуважаемого оппонента. Ну не язык системного программирования Оберон, и все тут. Ok. Изучим этот тезис.

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

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

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

«Под системным программированием я понимаю реализацию программных систем, безотносительно их области применения»

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

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

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

Постепенно начинаю понимать причину недопонимания. И главное, -- его истоки. Когда шло обсуждение неквалифицирующего и квалифицирующего импорта, я не задумываясь фиксировал для себя контекст ("раздельная компиляция", а как же еще?). Действительно, теоретически можно считать, что существует неквалифицирующий импорт и в случае независимой компиляции. Но, пардон, тогда это вообще не импорт. Это просто использование внешних символьных имен ("использование"). Понятие "импорт" появилось в паре с понятием "экспорт" применительно к модулю в начале 1970-х годов, где первыми ласточками были Mesa и CLU. Именно тогда и появилась раздельная компиляция. Но узаконили ее более известные языки: Модула-2 и Ada. Тем не менее, в силу особого положения Си и C++ граница в сознании программистов между независимой и раздельной компиляцией была почти полностью размыта. Откройте одно из самых первых справочных руководств по Си -- "C Reference Manual" Денниса Ритчи (1975), где ничтоже сумняшеся используется фраза "separately compiled pieces". То бишь что независимая, что раздельная -- одно и то же.

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

Если говорить о том, какая здесь творится неразбериха в головах, вот небольшая цитата, только что попалась на глаза: 4.6.Модульное программирование на Си. Файл Си-программы как элемент модульного программирования. Под модульным программированием понимается процесс разработки программы из  нескольких логически завершенных единиц -- модулей. В Си такой логической единицей программирования является функция. Но кроме этого еще одной, но уже физической единицей программы является текстовый файл, содержащий некоторое количество функций и определений типов данных и переменных. Модульное программирование на уровне файлов -- это возможность разделить полный  текст программы на несколько файлов, транслировать их независимо друг от друга. http://docs.h1.ru/cidocs/vdv_14191/gl46.html

Чем не модульное программирование? :) А мы тут еще что-то обсуждаем. Хотя, что тут говорить, если даже Т.Пратт и М.Зелковиц ("Языки программирования. Разработка и реализация", 2002) запутали вопрос окончательно (у них separate compilation -- это гремучая смесь независимой и раздельной компиляции).

Для введения в данную проблематику и снятия большинства вопросов стоит обратить внимание на ETH-диссертацию R.Crelier -- "Separate Compilation and Module Extension" (1994) http://www.europrog.ru/paper/eth10650.pdf
Вот небольшая выдержка из нее: Some programming languages and assemblers avoid this problem by introducing external declarations informing the compiler that an object with the given name exists and is declared somewhere outside the currently compiled module. Usually, the external declaration mentions neither the exact origin of the object, nor its type, which makes interface checking impossible; and even if the type is provided, there is no guarantee that it is the right one. In that case, one speaks of independent compilation, in contrast to separate compilation, the latter performing full interface checking. Independent compilation will not be considered further here, since the techniques presented in this thesis improve the implementation of import-export mechanisms in modular programming languages like Modula-2 or Oberon, which already guarantee type safety across module boundaries.

Требованиями для полноценной раздельной компиляции (separate compilation) являются:
1) разделение модуля на две части -- публичную (интерфейс, definition) и приватную (реализация, implementation);
2) раздельная трансляция интерфейса и реализации (интерфейс может быть оттранслирован при отсутствии (зоне действия компилятора) его реализации, обратное неверно);
3) гарантия контроля на этапе компиляции всех декларированных свойств экспортируемых сущностей (включая типы, способы/режимы передачи параметров и т.п.);
4) при трансляции реализации данного модуля -- необходимость наличия оттранслированных интерфейсов (заморозка версий!) всех импортируемых им модулей;
5) явное указание в реализации всех импортируемых интерфейсов.

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

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

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

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

Ответ на »сообщение 3916« от (Антон Григорьев)
___________________________
в) логика элемента не должна включать в себя логику системы, то есть, не должна содержать даже намека на межмодульные связи»
Ни одного возражения (даже комментария) от «оберонщиков»...

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

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

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

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

Ответ на »сообщение 3915« от (Руслан Богатырев)
___________________________
Во-первых, мне непонятно, почему система ценностей человечества (или хотя бы научной его части) должно расходится с «нашей системой ценностей». Может быть Вы возьмете на себя труд, объяснить, чем общепринятое понятие «система» отличается от понятия «системы» в  программировании.

Да потому что так устоялось десятилетиями... Может быть, повоюем против понятия "комплексное число", потому что непонятно, каким образом оно связано со словом "комплекс"? :-)


Во-вторых, я уже пояснял свое понятие системного программирования. Может быть Вы не сочтете за труд читать сообщения оппонентов?.. Повторю, «Под системным программированием я понимаю реализацию программных систем, безотносительно их области применения». ( см. »сообщение 3902« ) Ничего... личного...
Прекрасно, никто не возражает против, того что лично Вы под этим понимаете нечто другое, нежели то, что описано в любом энциклопедическом словаре computer-science-направленности.
Но тогда становится бессмысленным Ваш вопрос: "Почему Вы утверждаете, что Оберон удобен для системного программирования?" - да про системное программирование в Вашем смысле рассуждения и не велись.