Три дня без интернета и на чтение ветки ушел час :)
Отвечать на ушедшие далеко в историю посты по отдельности уже нет смысла.
Руслан Богатырев назвал режим общения полудуплексным, мол он чужое читает, а его ответы то ли не читают, то ли не понимают. Руслан, ситуация абсолютно симметричная, Ваши ответы тоже не о том :)

Ответ на »сообщение 4253« (Takun)
___________________________
(Продолжение)

К чему это все было? Мне вспомнилась одна методология или мат. модель, которая имеет отношение как к Оберонам, так и к системам по ASU. За исключением сверх-идей, про которые я уже говорил: то, что, ASU называет над-уровнем следует называть системой управления, а сверх-идею - моделью :-). (Все как обычно имхо).

Значит цепочка моих ассоциаций:
Оберон -> Гуткнехт -> Active Oberon, Zonnon -> Milners new computing model ->
Робин Милнерс (Robin Milners) -> Биграфы -> Агрегация, слабые(динмаические связи) -> ASU.

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

Не знаю, будет ли это кому полезно, но (опять имхо) это возможность повернуть разговор в конструктивное русло.

Можно так же вспомнить, что агрегация и каналы - это то, что отличает AO от Zonnon'а. Неспроста все это ;-)

Ответ на »сообщение 4245« (ASU)
___________________________
PS. Господа, я готов отвечать на Ваши вопросы, но давайте рассматривать вопросы создания систем в отдельной теме.

Сформулируйте тему и она будет создана.

"Life was simple before World War II. After that, we had systems."
Grace Hopper

Позволю себе тоже высказаться :).

Обыскался тут, где у ASU было внятное определение системы... Ну пусть будет »сообщение 4149«:

Логика всегда сконцентрирована в над-уровне (в над-системе). Реализация этой логики может быть передана на нижние уровни. Конструктор соединил две части, теперь часть А «намертво» привязана к части Б. Мы не знаем ни конструктора, ни его замысла.
...
«Слабые» связи есть всегда и есть над-уровень, даже если мы его не можем наблюдать непосредственно.

Ничего, что я подсокращу? Контекст можно посмотреть в исходном сообщении.
Вот... Возьмем в качестве учебного примера Интернет (раз уж компилятор не погодился ;-) ).  Уровни у него есть (если исходить из модели в виде стека протоколов). Объектов полно, слабых связей тоже. Практически все можно выключить или заменить без потери его системности.
Надеюсь никто не скажет, что Интернет маленькая система?
Спрашивается, в каком месте у него над-уровень?
Логично предположить, что сверху. Но среди многочисленных прикладных служб, как то: Web, FTP, Email, Emule, DNS, Usenet и т.п., и т.д. я не вижу ничего, что бы являлось для Интернета определяющим. Да, без DNS было бы тяжко, но если заменить его альтернативным решением, то Интернет Интернетом быть не перестанет.
Можно предположить, что глупые архитекторы нарисовали стек протоколов "кверх ногами" и над-уровень у него снизу? И логику системы определяет шаг скручивания витой пары?
Выводы достаточно абсурдны, что бы можно было не развивать их дальше.
Как это ни странно, над-уровень у Интернета находится посередине :), А именно в сетевом слое. Более конкретно основой Интернета является технология коммутации пакетов. "Сверх идея" Интернета в том, что эти пакеты доставляются не зависимо друг от друга. Полезным следствием этой "сверх идеи" является то, что сложно построить систему тарификации зависящую от того, куда вы передаете пакеты, а негативным - сложность построение систем безопасности. В качестве иллюстрации: при замене коммутации пакетов на коммутацию каналов, на сайте Королевства вы бы прочли:
На Королевстве проводится очередной конкурс «Рыцари Круглого стола»
Пришлите SMS на IP адрес X.Y.Z, цена SMS 2.00 y.e.

8-[ ]
Итак, резюмируя:
1) Логика системы сосредоточена не в над-уровне, а в связующем уровне, в характеристиках связей стистемы.
2) Логика системы определяет лишь некоторые свойства системы (определяет некоторый класс систем?).
3) "Сверх идея"... Мда... По видимому развитая, система вполне жизнеспособна без всякой сверхидеи.
4) В качестве (необязательного) над-уровня можно рассматривать систему управления постноенной на основе некой модели системы (рекурсия?). Адекватность модели отдельный вопрос.

(Продолжение следует)

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

В Обероне любой модуль может импортировать все, что экспортировано другими модулями, нет ни каких ограничений... Соответственно, и экспортировать модуль может любые свои «потроха»... опять же без каких либо ограничений.

Несколько не понимаю.
Список экспорта это контракт.
Т.е. "если вы мне далите некое вещественное число X то я вам верну Y - значение синуса этого числа в радианах"
Вы знаете только про процедуру sin и две переменных X (на вход) и Y (на выход).
Но Вы НИЧЕГО незнаете про потроха, в виде счётчика I, с помощью которого в процедуре считается ряд, который и даёт нам значение Y=sin(S).
Т.е. вы знаете о процедуре ровно то, что она хотела Вам сказать о себе.

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


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


Ну ... вобщемнто .... вы описали модули Оберона ...
Правда Оберон даёт только три уровня иерархи:
1)переменная
2)процедура
3)модуль
Ни кто Вам не мешает создать переменнаую А в процедуре А в модуле А
Но если Вы захотите:
1) в процедуре А создать ещё одну переменную А
2) в модуле А создать ещё одну процедуру А
3) создать ещё модуль А
То получите по рукам.

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


Вы считаете, что эту схему нельзя создать на ассемблере? Тогда чем же ЯВУ отличаются от ассемблеров? Согласитесь, что подобная постановка вопроса не совсем корректна.

Ну если на то пошло, то компьютер основан на Булеврй алгебре, такчто И, ИЛИ, НЕ ...

Реализацию данной схемы на ассемблере я вижу следующим образом:
1) реализуем на ассемблере конструкции, соответствующие операторам цикла, присваивания, проверки условия, создаём механизмы рамещения в памяти переменных различных типов
2) создаём механизмы объединения операторов и ограничения области видимости переменных а также обеспечивающий интерфейс с другими элементами. Назавём это ... ну... например процедуры.
3) создаём механизм, позволяющий объеденить несколько процедур, и обеспечивающий жесткий контроль общения своих внутренних процедур с различными внешними элементами. Скажем это будет модуль.
4) создаём элемент, позволяющий на базе модулей дингамечески формировать системы. Назавём его системобразующим элементом.

Элементы 1-3 реализованы в Обероне и их достаточно (ИМХО) для реализации 4. Я не вижу проблем написать Оберон на ассемблере. Равно как и смысла это делать, т.к. он уже реализован на Обероне.

СЭ берётся не из воздуха а строится на базе ранее существующих элементов.
Плюс некие доплнительные возможности.

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

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

>>>PS. Господа, я готов отвечать на Ваши вопросы, но давайте рассматривать вопросы создания систем в отдельной теме.

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

Ответ на »сообщение 4248« (Антон Григорьев)
___________________________

Я имел ввиду модульное программирование в понимании Оберона. Вы же, надеюсь, не будете утверждать, что никогда не критиковали ту систему организации модулей, которая присуща Оберону?
Никакой системы организации модулей модулей в Oberon просто нет. Как же я мог ее критиковать...  А если Вам есть, что сказать вот по этому поводу: «логика элемента не должна включать в себя логику системы, то есть, не должна содержать даже намека на межмодульные связи», - то я рад бы был услышать Ваше мнение. Если я неправ, то скажите в чем, а если прав... :)))

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

Заодно и критерий предложить, как отличать одни случаи от других - словом, всё то, о чём я писал в предыдущем сообщении
Хм?.. А разве я не говорил о критериях?.. Как же, как же... говорил. Даже сравнивал программы и системы... Запамятовали? :)))

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

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

И понятно, чем всё это закончится: скоро вы начнёте говорить, что уже всё сказали и на все вопросы ответили, только вот собеседники не понимают
Именно... Что Вам конкретно непонятно?.. Ну, не можете же Вы меня обвинять в том, что Вам лень самому сделать проекцию теории систем, на практику программирования. Это весьма просто... как видите... хотя, нет, не видите... :)))

Я, конечно, помню из другой ветки, что у вас были откровения, благодаря которым вы знаете истину (цитаты поискать, или и так не будете отпираться?)
Отпираться?.. Помилуйте, об этом только мечтать можно!.. А уж если случилось, то... :)))

и, соответственно, не всегда можете доказать то, что знаете, логически, потому что свои знания получаете отнюдь не при помощи логики
Знания... нет... Вы и другую «ветку» читали крайне невнимательно... к сожалению... :)))

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

Но вы уж, пожалуйста, постарайтесь как-нибудь рассказать нам, чем же мы должны заменить модули, и как-то это обосновать
Рассказываю... Модули заменять ничем не надо... Удовлетворены?.. (догадываюсь, что нет, но...) :)))

А то ваш снисходительно-покровительствующий тон уже изрядно надоел.
Зато я в восторге от модератора!.. От столь беспристрастной пристрастности... :)))

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

А теперь приведите хоть одну цитату, где я критикую модульное программирование... Ха-ха-ха-ха...

Я имел ввиду модульное программирование в понимании Оберона. Вы же, надеюсь, не будете утверждать, что никогда не критиковали ту систему организации модулей, которая присуща Оберону?

Но в Обероне царит анархия, когда надо установить межмодульные связи. Каждый делает то, что счел нужным и то, как счел нужным... Никаких правил, никакого контроля (кроме проверки соответствия типов формальных и фактических параметров), никакой логики (концепции)... - »сообщение 4149«

логика элемента не должна включать в себя логику системы, то есть, не должна содержать даже намека на межмодульные связи - »сообщение 3926«

А ещё вы говорили, что использование модулей надо ограничить - их универсальность только вредит

Чего Вам так нравится универсальность модулей... Ну, неудобно молотком щи хлебать... неудобно. Я не отрицаю полезность модулей, но для декларирования при моделировании мне никакие модули не нужны... Нужен инструмент, который проводит это описание через все стадии проектирования, разработки, тестирования и эксплуатации. Это не языковые (в смысле, не 3GL) средства, я об этом с самого начала говорил... - »сообщение 4014«

Ну и так далее. Теперь, казалось бы, самое время престать говорить о том, чего в обероновских модулях не хватает и начать говорить о том, какой механизм мог бы их заменить в тех случаях, где они не подходят. Заодно и критерий предложить, как отличать одни случаи от других - словом, всё то, о чём я писал в предыдущем сообщении. Но эти мои слова вас не заинтересовали, вы выдрали из всего сообщения одну далеко не самую важную фразу, придрались к ней и на этом успокоились. Что ж, это ещё одно доказательство, что ничего конкретного сказать вы не можете. Налить воды с позиций теории - это пожалуйста, скоро от неё захлебнёмся, а вот когда дело доходит до конкретных предложений - это не к ASU. И понятно, чем всё это закончится: скоро вы начнёте говорить, что уже всё сказали и на все вопросы ответили, только вот собеседники не понимают. Впрочем, почему начнёте? Уже начали. Мне кажется, что кто хотел услышать – услышал... Надо ли «толочь воду в ступе»? (»сообщение 4193«).

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

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