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

Ответ на »сообщение 4252« (MS)
___________________________
Список экспорта это контракт.
Контракт с кем? Контракт (договор) предусматривает более одной стороны...

Хорошо :-) Не контракт. Бланк контракта, который модуль затем подписывает с каждым, кто хочет его использовать :-)

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

Ответ на »сообщение 4241« (Geniepro)
___________________________
Я имею в виду старую работу Роу и Шиперски о легковесном параметрическом полиморфизме для Оберона (примерно 1997).

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

А полноценная параметризация в настоящий момент технически не вяжется с динамической модульностью. И "вязаться" она начнет только после одного события - перехода какой-либо из магистральных реализаций Оберонов (Ящика али Бутылки) на промежуточное представление Франца и JIT. Но пока до этого руки не доходят ни у них, ни у нас...
Кстати, к радости Сергея Перовского отмечу, что после введения JIT спектр изменений, допустимых без перекомпиляции, весьма расширится. В частности, можно будет ввести в базовый тип дополнительные методы, не нарушая работу клиентов...

Ответ на »сообщение 4252« (MS)
___________________________
Список экспорта это контракт.
Контракт с кем? Контракт (договор) предусматривает более одной стороны...

Ну ... вобщемнто .... вы описали модули Оберона ...
:)

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

Вот я и задумался о применимости модульного подхода с прямым именованием одного модуля из другого.
С одной стороны модульность хороша именно для систем, там она проявляет свои лучшие качества. С другой стороны невозможность заменить модуль на другой (ПО ДРУГОМУ НАЗВАННЫЙ) подрывает идеологию систем возвращая нас к монолитным программам.

Модульный подход, реализованный в языке Оберон/КП, предсматривает обращение из модуля к интерфейсу (давайте это где-нибудь напишем большими буквами и повесим плакат). Реализации Оберона/КП (Oberon System, BlackBox) наглядно демонстрируют, что добиться динамической подмены реализации под заданный и зафиксированный интерфейс, это не только не проблема -- это основа упомянутых расширяемых систем. Но для этого нет надобности вводить динамику соответствия "интерфейс-реализация" на уровне языка. Достаточно их просто разделить, что и сделано в языке (DEFINITION -- отдельно, MODULE -- отдельно).

Когда есть интерфейс и реализация, возможны четыре варианта отношений:
1. один-к-одному (один интерфейс -- одна реализация)
2. один-ко-многим
3. многие-к-одному
4. многие-ко-многим

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

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

Ответ на »сообщение 4251« (MS)
___________________________
Реализацию данной схемы на ассемблере я вижу следующим образом:
1) реализуем на ассемблере конструкции, соответствующие операторам цикла, присваивания, проверки условия, создаём механизмы рамещения в памяти переменных различных типов
Эти «конструкции» давно есть в практически любом ассемблере для x86, например, (цикл – loop, присваивание – mov, проверка (сравнение) – cmp).

2) создаём механизмы объединения операторов и ограничения области видимости переменных а также обеспечивающий интерфейс с другими элементами. Назавём это ... ну... например процедуры.
Угу... "proc"... называется в ассемблере.

3) создаём механизм, позволяющий объеденить несколько процедур, и обеспечивающий жесткий контроль общения своих внутренних процедур с различными внешними элементами. Скажем это будет модуль.
Объединение процедур – библиотека, «библиотекари», как правило, входят в поставку ассемблера (но, не всегда).

4) создаём элемент, позволяющий на базе модулей дингамечески формировать системы. Назавём его системобразующим элементом.
Элементы 1-3 реализованы в Обероне и их достаточно (ИМХО) для реализации 4.
Элементы 1-3 реализованы в ассемблерах и с их помощью можно реализовать 4. :)

СЭ берётся не из воздуха а строится на базе ранее существующих элементов.
Плюс некие доплнительные возможности.
СЭ «берется» из элементов или элементы «берутся» из СЭ зависит от того, какого метода проектирования (нисходящий/восходящий) Вы придерживаетесь.

Важнейшим требованием становится наличие поддержки этих новых возможностей средой, в которой создаётся/функционирует система.
Я предложил некий механизм создания систем, основанный на возможностях Оберона.
Если он не вызывает у Вас возражений, то тогда следует вывод, что Оберон обладает средствами для разработки систем.
Да, как видите, и ассемблер ему в этом ничуть не уступает... следовательно, и ассемблер обладает средствами разработки систем... :)
Ну, и... что далее... :)

Ответ на »сообщение 4250« (AVC)
___________________________
Однако, отдельные вопросы (разбор модульности и т.п.) неплохо бы оставить здесь, т.к. они достаточно близки обероновской тематике.
Вроде бы уже все разобрали... «по косточкам»... :)

Как бы то ни было, IMHO, вырисовываются два дефекта обероновской модульной структуры:
IMHO... дефект всего один... экспорт-импорт вместо продуманных интерфейсов...

1) пространство имен модулей -- плоское (всего один уровень); в ББ с этим борются с помощью специального соглашения об именовании модулей, но, возможно, требуется лучшее решение;
Очень знакомая картина... Сначала создаем проблемы, потом с ними боремся... Вместо того, чтобы содержать дороги в порядке, ремонтируем автомобили... :)

2) все модули имеют одинаковый статус, в т.ч. модули "для внутреннего пользования" какой-нибудь подсистемы (см. »сообщение 4244«); возможно, неплохо бы разделить модули на public и private :) и ввести особый вид экспорта -- только в рамках подсистемы-кластера (отдаленный аналог protected в Си++).
Не совсем так... (если желаете, обсудим это в отдельной теме).

Ответ на »сообщение 4266« (Руслан Богатырев)
___________________________
>>>Для этого бедному крестьянину стоит призадуматься о применимости обоих подходов, выявляя контекст применения инструмента
Вот я и задумался о применимости модульного подхода с прямым именованием одного модуля из другого.
С одной стороны модульность хороша именно для систем, там она проявляет свои лучшие качества. С другой стороны невозможность заменить модуль на другой (ПО ДРУГОМУ НАЗВАННЫЙ) подрывает идеологию систем возвращая нас к монолитным программам.
Раз речь о системах, я и сравниваю с существующими системами. Когда я вызываю в своей программе кодек XviD, я понятия не имею (и не хочу), кодек чьей разработки и с каким названием будет подключен, это вопрос администратора системы. Я обращаюсь по имени интерфейса, а не по имени модуля. Поскольку это принципиально разные сущности, требовать совпадения их имен странно - это запутывает программиста в сложных случаях (в простых экономит некоторое время на написание).

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

Процедура реализует алгоритм ввода символа.
А система поддерживает ввод с клавиатуры.

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

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

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

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