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

Уже предложил... Но перечитайте то, что говорилось в защиту квалифицирующего импорта, прежде чем... говорить, что «никто не смотрит»...

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

Кстати, в том сообщении AVC, на которое вы отвечали, был конкретный вопрос: Допустим, у меня есть процедура foo в модуле M1, и процедура foo в модуле M2. Как должен решаться конфликт имен?

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

Вот ещё один ваш перл: Под системным программированием я понимаю реализацию программных систем, безотносительно их области применения.

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

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

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

И позиционирование Оберона, как языка системного программирования, совершенно необоснованно.

Ok. Мы работаем в сфере программирования, где давно существует своя система ценностей, своя терминология. Есть такой термин systems programming (системное программирование). Если не затруднит -- представьте свое понимание этого термина, раз он расходится с общепринятой точкой зрения.

Некое краткое введение в понимание этого термина в общепринятом смысле можно найти здесь: http://en.wikipedia.org/wiki/Systems_programming

Ответ на »сообщение 3889« (ASU)
___________________________
>>> Это я уже объяснил, и вроде бы меня поняли... почти все.

Правильно. Только, к сожалению, "почти все". Некоторые так и не раскусили.

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

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

>>>Вопрос: где объявляется ("находится") интерфейс? ("Где находится Нофелет?" :) )
Между уровнями системы... вестимо... (или Вы хотите знать название файла? :) )

Если Вас этот вопрос затрудняет, дам подсказку: кнопочки находятся на передней панели телевизора (или его remote control), но никак не человека. :)

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

Никто не смотрит на квалифицирующий импорт через "розовые очки".
Как только Вы предложите лучший механизм, все сразу забудут о квалифицирующем импорте.

Алексей, давайте попробуем немного порассуждать. Итак, в дискуссии по квалифицирующему импорту помимо Оберона/КП были затронуты такие языки, как Модула-2 (прямой предшественник Оберона), Delphi (язык, хорошо знакомый посетителям данного сайта), Haskell (наиболее обсуждаемый здесь представитель ФП-направления).

Вопрос ASU, озвученный в »сообщение 3856«, звучал так: Может быть подскажите, как квалифицированный импорт сочетается с "системностью" Oberon?

Т.е. нарекание/сомнение вызывали не модули Оберона, не экспорт-импорт, а именно квалифицирующий импорт. По всей видимости предполагалось, что он никак не сочетается с "системностью".

Смотрим развитие дискуссии дальше. »сообщение 3882«: Речь о том, что прикладной программист не должен знать, что и откуда будет импортироваться и куда экспортироваться. Он не должен(!) на уровне модуля прописывать системную логику, те самые «слабые» связи. «Слабые» связи не должны быть компетенцией языка разработки. Это задача системного линкера при статическом связывании или системного загрузчика при динамическом связывании.

Далее. В »сообщение 3887« в ответ на мое раскрытие термина "неквалифицирующий импорт" прозвучала реплика: Очень правильно. На мое раскрытие термина "квалифицирующий импорт" -- реплика Очень неправильно (с позиций системности)...

Этой информации IMHO вполне достаточно, чтобы вести дальнейшие рассуждения. Итак, тезис ASU: неквалифицирующий импорт -- правильно с позиций системности, а квалифицирующий импорт -- неправильно. Обоснование: "Слабые" связи не должны быть компетенцией языка разработки, это задача системного линкера/загрузчика.

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

Хорошо, пусть так. Зададимся вопросом, когда наступает конкретизация и кто/что ее обеспечивает? ASU, насколько я понял, -- категорический противник конкретизации на уровне исходного текста языка реализации. Следовательно, процесс конкретизации (установление связи "сущность --> модуль") должен выноситься на другие этапы, за которые отвечают соответствующие инструментальные средства:
1. компилятор
2. компоновщик (редактор связей, линкер)
3. загрузчик

Фактически мы приходим к ретроспективе эволюции взглядов на технологический  процесс программирования. Одной из первых была независимая компиляция (independent compilation, яркие примеры -- Фортран, Си): внешние сущности (подпрограммы) размещались в сторонних библиотеках (они тогда и играли роль модулей). Программист просто знал (из документации), что есть некая полезная подпрограмма (ее имя, набор параметров и функциональность). Он мог ее использовать. На этапе компиляции конкретизации не было. Она откладывалась до следующего этапа -- редактирования связей (linkage, компоновки, линковки). Редактор связей, используя информацию о конфигурировании (что "подцеплять"), и занимался конкретизацией.

Постепенно пришло понимание, что такая гибкость влечет за собой огромные проблемы в контроле сложности и обеспечении надежности. Контроль версионности реализации для внешних библиотек (и сущностей из них), контроль параметров -- не могли осуществляться. Тогда пришли к понятию интерфейса, который воспринимался как подробная спецификация экспорта модуля. Интерфейс -- это та недостающая компилятору информация, которая позволяет осуществлять контроль (сущностей, параметров, версионности). Она же является "путевым листом" модуля для линковки и загрузки. Разбиение модуля на две части -- видимую другим (интерфейс) и скрытую (реалиазация) привел к понятию раздельная компиляция (separate compilation, яркие примеры -- Модула-2, Ada). Теперь можно было раздельно компилировать любую реализацию модуля при наличии всех необходимых интерфейсов (данного модуля + всех импортируемых им модулей).

Итак, на смену отображению "сущность --> модуль" пришло промежуточное: "интерфейс --> модуль", которое привело к схеме "сущность -> интерфейс --> модуль". При этом модули могли оперировать внешними сущностями только из интерфейсов.

Что это дало: в совокупности с увеличением надежности конкретизация не переместилась на этап компиляции (ведь там связывались только реализации с интерфейсами). Она происходила на этапе линковки/загрузки, но уже с гарантиями подписанных всеми сторонами "контрактов" (интерфейсов). Линкер/загрузчик по-прежнему имеет возможности хинтовки (конфигурирования) для осуществления конкретизации.

Собственно, подавляющее большинство современных языков перешло на схему раздельной компиляции. И если именно она вызывает вопросы, давайте ее всесторонне обсуждать. Думаю, ASU не призывает нас возвращаться к Фортрану и Си, уже прошедших по этим граблям.

Значит, остается раздельная компиляция, в которой и интересует квалифицирующий импорт. С точки зрения компилятора (а другие этапы можно уже и не рассматривать, если останавливаемся на схеме раздельной компиляции), разницы между квалифицирующим и неквалифирующим импортом по сути нет. Именно компилятор должен установить соответствие "сущность --> интерфейс" (логическая конкретизация), тогда как соответствие "интерфейс --> модуль (реализация)" (физическая конкретизация) переносится на этапы линковки/загрузки.

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

Так что же отличает эти два вида импорта? Только одно -- программист. В случае неквалифицирующего импорта он не хочет себя обременять знаниями о том, к какому интерфейсу относится та или иная сущность (хотя знания уже есть, ими обладает компилятор и никто здесь уже вмешаться потом не может!). Он передоверяется автопилоту. Пример проблемы в Delphi я уже приводил -- указываете перечень импортируемых модулей в одном порядке -- подключается один интерфейс к данной сущности, в другом порядке -- другой. Программист почти наверняка это не заметит. В случае квалифицирующего импорта компилятор строго выполняет инструкцию программиста по установлению логической (не физической!) связи "сущность --> интерфейс". Если заботит избыток текста -- нажмите Hide, квалификация исчезнет (с экранов радаров, но не в действительности); нажмите Show -- появится. При этом уже нельзя будет ввести обращение к внешней сущности без указания квалификатора.

Итак, все обсуждение сводится к простому -- "автопилот" квалификации (при компиляции) с разрешением коллизий против явного указания программиста. Никакого ущемления "системности" здесь нет.

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

>>>Описание интерфейса доступно и проверить соответствие не труднее, чем при вызове подпрограммы.

Я неустанно спрашиваю, где "находится" интерфейс, каким образом он доступен компилятору? :)

Линкеры и библиотекари "в свое время" никак указанную задачу не решали.
То есть... как это не решали?

Да так -- не решали и все. :)
Возьмем типичный пример: компиляцию и сборку сишной программы.
Никакого контроля типов для объектов другого модуля при компиляции не делалось.
В лучшем случае, принималось на веру, то, что было написано в h-файле.
В худшем, "интерфейс" задавался функции "по умолчанию": считалось, что функция возвращает int, а типы аргументов брались из первого вызова. Т.е. имело место гадание, а никак не контроль типов.
А линкер вообще типами не занимался, а занимался только настройкой адресов.
Допустим, я вызываю функцию foo.
Компилятор превращает это в команду call _foo, а линкер определяет смещение некоего объекта _foo относительно текущего значения pc.
Роль линкера иногда была столь незначительна, что в системе программирования для последнего микропроцессора я вообще выкинул отдельный линкер, у меня линковкой сразу занимается ассемблер (в данном конкретном случае это проще и быстрее).

Ответ на »сообщение 3908« (AVC)
___________________________
>> Понимаете, интерфейс – это набор протоколов, соглашений, деклараций, одним словом.

Да, понимаю.
Вопрос: где объявляется ("находится") интерфейс? ("Где находится Нофелет?" :) )
Между уровнями системы... вестимо... (или Вы хотите знать название файла? :) )

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

Ответ на »сообщение 3905« (Geniepro)
___________________________
>> Макроязык внутри Оберон?..
Вот-вот, Вы поинтересуйтесь у наших уважаемых оберонщиков, что есть в их понимании метапрограммирование.
Как я понял, метапрограммирование в Обероне очень сильно расходится с традиционным метапрограммированием...
Похоже не только термин «метапрограммирование», но и системное программирование, модули и много чего еще... В принципе, это не так страшно, страшно, когда «создают себе кумира» :)

ЗЫ. Да, кстати, тот самый DLL-hell, который Вы, похоже, считаете правильным системным подходом, в Оберонах запрещён принципиально.
О том и речь...

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

>>>Понимаете, интерфейс – это набор протоколов, соглашений, деклараций, одним словом.

Да, понимаю.
Вопрос: где объявляется ("находится") интерфейс? ("Где находится Нофелет?" :) )
Например, интерфейс электрической кухонной плиты -- ручки, меняющие нагрев конфорок.
Интерфейс телевизора -- кнопочки, позволяющие переключать программы, менять громкость, яркость и т.д.
Вы не подмечаете некоторой закономерности? :)

Ответ на »сообщение 3901« (AVC)
___________________________
>> Вопрос на засыпку: а как компилятор будет осуществлять межмодульный контроль типов до того как в дело вступит системный загрузчик?
А... вот... никак... и не будет. Не его это ума дело... Были в свое время линкеры... библиотекари... а сейчас "на все про все" осталось... F9. :)

Интересно, как компилятор будет генерировать код для сущности, чей тип неизвестен?
Какой код? Для какой сущности?.. Есть некий интерфейс, и при обращении к нему подставляется код вызова (синхронное обращение) или код посылки сообщения (асинхронное обращение). Описание интерфейса доступно и проверить соответствие не труднее, чем при вызове подпрограммы.

Линкеры и библиотекари "в свое время" никак указанную задачу не решали.
То есть... как это не решали?