Ответ на »сообщение 3926« (Руслан Богатырев)
Посмотрите, пожалуйста, указанный фрагмент статьи Свердлова и скажите, вы по-прежнему настаиваете, что "языковой модуль -- это всего лишь namespace" ?

Я уже читал ту статью раньше.

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

Без комментариев.

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

Сергей Губанов абсолютно прав.
Никакого противоречия в его рассуждениях нет -- есть словесная неточность: у него сказано "модульные языки" вместо "модульные системы", о которых он все время толкует.

Ответ на »сообщение 3925« (Руслан Богатырев)
Напомните, пожалуйста, с какого года проф. Вирт занимается созданием упомянутых вами систем.

Не напомню. Вы это и сами прекрасно знаете. А сейчас притворяетесь что забыли.

Вывод: в немодульных языках есть namespace (языковой модуль), т.е. есть модуль (см. п.1), но при этом в них модулей нет (см. п.2).

Модульный язык - язык оптимизированный для написания модульных систем.
Немодульный язык - язык не оптимизированный для написания модульных систем.

скажите, какие из следующих языков являются модульными (с вашей точки зрения): C++, Java, C#, Delphi, Eiffel, Smalltalk.

Ни один из них. Ни один из них не оптимизирован для написания модульных систем. Предвосхищая возможные возражения на счет Delphi: unit - не является модулем  какой-то модульной системы, а является некой промежуточной субстанцией.

Можно ли с помощью модулей создавать немодульные системы? Может ли внутри немодульной системы быть хотя бы один модуль?

Если нет модульной системы, то что такое модуль? Модуль чего?

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

модификаторы ООП (ABSTRACT, EXTENSIBLE, LIMITED и др.), которые, собственно, и определяют лицо этого языка...

А все остальное как же??
Да, на фоне других Оберонов эти оособенности отличают именно Компонентный Паскаль.

Но на фоне всего остального?!

Компонентный Паскаль Куно Пфистера и Клеменса Шиперски ведет отсчет от 1997 г.


Коллекционер Вы наш...
Компонентный Паскаль появился в 1999 г.
Активный Оберон к тому времени существовал уже годы.

Руслан, Вы упорно продолжаете кампанию раздувания отличий Компонентного Паскаля от классического Оберона.
Совершенно очевидны Ваши цели личного позиционирования.

Я бы предпочел побольше мыслей в Ваших постингах. Тогда и позиционирование само собой получится. Настоящее.

Ответ на »сообщение 3924« (Сергей Губанов)
___________________________

Относительно namespace (пространство имен). Обладает ли пространство имен такой характеристикой, как область существования принадлежащих ей сущностей?

Вопрос задан неспроста: модуль характеризуется тем, что задает область видимости (и уровня доступа), а также область существования принадлежащих ему сущностей. Пространство имен имеет отношение только к области видимости.

В своей статье "Язык программирования Си#: критическая оценка" Сергей Свердлов подверг критике пространства имен в языке Си#. См. http://www.pcweek.ru/?ID=65948

Посмотрите, пожалуйста, указанный фрагмент статьи Свердлова и скажите, вы по-прежнему настаиваете, что "языковой модуль -- это всего лишь namespace" ?

Ответ на »сообщение 3924« (Сергей Губанов)
___________________________

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

:o)

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

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

Относительно противоречий в ваших высказываниях.

1. Языковой модуль - это всего лишь namespace. Поэтому в немодульных языках программирования namespace в большом почёте - а им больше и не надо!

Т.е. языковой модуль = namespace

При этом "всего лишь" в данном контексте имеет смысл "не более, чем" (т.е. подмножество, частный случай).

2. Да, в немодульных языках есть текст и только текст. А вот в модульных языках, кроме текста еще есть модули. Инструкция IMPORT - это не импорт текста, а импорт модуля. Текста импортируемых модулей для модуля клиента - нет.

Т.е. в немодульных языках модулей нет (есть текст и только текст).

Вывод: в немодульных языках есть namespace (языковой модуль), т.е. есть модуль (см. п.1), но при этом в них модулей нет (см. п.2).



Понимаю, что с определением возникают затруднения. Тогда для определенности (чтобы хотя бы понять, что вы считаете модульными языками, а что немодульными) скажите, какие из следующих языков являются модульными (с вашей точки зрения): C++, Java, C#, Delphi, Eiffel, Smalltalk.

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


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

Ответ на »сообщение 3867« (Сергей Перовский)
Большинство программистов предпочтет разбить свой текст на отдельные части.

Можно подумать, что сделают они это потому, что, ну, тексту не хватило места в одном документе :-).
Не текст бъётся на части, а система компонуется из компонентов.

Механизм раздельной компиляции и механизм раздельной загрузки выдвигают различные требования к своим единицам.

Объясните в чём разница в требованиях к дельфийскому unit и к оберонстому MODULE? Я, например, разницы в требованиях не вижу.

Ответ на »сообщение 3872« (Руслан Богатырев)
Вывод: модуль (в понимании С.Г.) не является понятием, воплощаемым на уровне исходных текстов. Что и требовалось доказать.

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

Ответ на »сообщение 3874« (Сергей Перовский)
Если мы рассматриваем язык - то речь идет всего на всего о правилах оформления текстов и выделении текстовых единиц. Текст делится на отдельные САМОСТОЯТЕЛЬНЫЕ тексты.
Целью является упрощение создания и понимания отдельных текстов и их повторное использование.

Да, в немодульных языках есть текст и только текст. А вот в модульных языках, кроме текста еще есть модули. Инструкция IMPORT - это не импорт текста, а импорт модуля. Текста импортируемых модулей для модуля клиента - нет.

Ответ на »сообщение 3897« (Руслан Богатырев)
Вирт -- сторонник первого подхода, где модули первичны, а все остальное (включая классы) вторично.

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

Ответ на »сообщение 3903« (hugi)
1) Концепция модуля базируется на концепции абстрактного типа данных.

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

Ответ на »сообщение 3909« (Руслан Богатырев)
Хорошо бы разобраться в языковых модулях (на уровне языка программирования), а не браться за все сразу.

Языковой модуль - это всего лишь namespace. Поэтому в немодульных языках программирования namespace в большом почёте - а им больше и не надо!

Ответ на »сообщение 3903« (hugi)
___________________________
Использование модулей аналогично следующей ситуации: мы покупаем в магазине торт, а потом, если нам что-нибудь потребовалось произвести с ним некоторые операции (разрезать, например), несём его обратно в магазин, чтобы там с тортом сделали всё, что нам нужно. В случае с классами мы просто покупаем торт, а операции с ним совершаем сами (точнее торт осуществляет операции над собой :)), мы лишь должны инициировать действие, т.е., например,  взять нож и начать резать, а как это действие будет осуществлено, решит наш конкретный торт; в магазин каждый раз бегать уже не надо.

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

Ответ на »сообщение 3901« (Горбунов-Посадов)

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