Ответ на »сообщение 3445« (Булат Зиганшин)
___________________________

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

Как именно поддерживают раздельную компиляцию некоторые "современные" языки хорошо видно по меню любого IDE для C++. Практически всегда там есть пункт "Rebuild all".

эмоции, конечно, хорошая вещь, но золотой браслет остаётся навсегда ;)

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

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

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

Как именно поддерживают раздельную компиляцию некоторые "современные" языки хорошо видно по меню любого IDE для C++. Практически всегда там есть пункт "Rebuild all".
Это говорит о том, что без явной поддержки модульности поддерживать синхронизацию частей программы не так просто, а контроля соответствия типов нет вообще.


эмоции, конечно, хорошая вещь, но золотой браслет остаётся навсегда ;)

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

в ghc я делаю rebuild только при смене компилятора

Ответ на »сообщение 3442« (Булат Зиганшин)
___________________________

>>>ps: кстати, я вспомнил. unit'ы в TP4 были один в один содраны из ms pascal, где они появились ещё в первой половине 80-х

Вероятно, в таком виде unit'ы впервые появились в UCSD Pascal в 1970-е годы.

Ответ на »сообщение 3442« (Булат Зиганшин)
___________________________

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

Как именно поддерживают раздельную компиляцию некоторые "современные" языки хорошо видно по меню любого IDE для C++. Практически всегда там есть пункт "Rebuild all".
Это говорит о том, что без явной поддержки модульности поддерживать синхронизацию частей программы не так просто, а контроля соответствия типов нет вообще.

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

спасибо за подробный ответ. я имел в виду, конечно, Модулу-2 как наиболее популярный из этих языков. кстати, вам возможно будет интересно http://rsdn.ru/Forum/Message.aspx?mid=2339757&only=1 где я анализирую причину победы в 80-х годах C/C++ как наиболее популярного языка прграммирования

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

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

ps: кстати, я вспомнил. unit'ы в TP4 были один в один содраны из ms pascal, где они появились ещё в первой половине 80-х

вообще, если вспомнить, наиболее популярные программы позволяют устанавливать модули, расширяющие их функциональность. достаточно вспомнить winamp и порчие плееры, far, total commander, архиваторные оболочки т.е. для того, чтобы сделать программу расширяемой - это очень удобно

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

Ответ на »сообщение 3439« (Булат Зиганшин)
___________________________

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

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

Ответ на »сообщение 3439« (Булат Зиганшин)
___________________________

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

Если говорить кратко -- прежде чем рассуждать в отношении модулей и модульного программирования, стоит в этом немного разобраться. Думаю, Вы понимаете, что есть некоторая разница между функцией языка Паскаль и функцией языка Haskell. Но называются обе вещи одним словом и кое-что их все же роднит. В отношении модулей разных языков ситуация обстоит подобным образом. На сегодняшний день виртовская линия Modula-2 -- Oberon осталась, пожалуй, наиболее цельной с точки зрения реализации концепции модуля как ключевого строительного блока языка (а не вспомогательного, как в других языках).

В языках функционального программирования (ФП) ключевой сущностью является функция, в языках ООП -- класс, в языках модульного программирования (МП) -- модуль.

Modula -- это язык модульного, а не модельного программирования. Разработан он был Никлаусом Виртом примерно в 1975 г. на основе:
1. Идеи модуля, изложенной в работах Дэвида Парнаса (а ранее -- в работе Петера Наура).
2. Работ по абстрактным типам данных в MIT (Барбара Лисков, язык CLU, 1972-1975)
3. Работ по параллельному программированию (Пер Бринч Хансен, Concurrent Pascal, 1974-1975).

Главным побуждающим мотивом Вирта было желание попробовать новый вариант Паскаля в сфере мультипрограммирования (параллельные процессы и встроенные системы). Он взял за основу фундамент классического Паскаля (1970-1972 гг.), идею Симулы-67 (сопрограммы), а также работы Дейкстры, Хоара и Пер Бринч Хансена в отношении создания концепции монитора (monitor, 1972). В этом каркасе модуль выполнял функции:
* основной единицы сокрытия информации (экспорт-импорт),
* единицы инкапсуляции (объединения данных и обрабатывающих их кода),
* единицы взаимоисключающего доступа к разделяемым ресурсам (мониторы -- interface module)
* единицы прямой работы с оборудованием (драйверы, модули устройств -- device module) с поддержкой уровней приоритетов прерываний (специфика PDP-11).

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

В языке Modula нельзя отделить спецификацию интерфейса от реализации. Сущности могут экспортироваться-импортироваться через границу модуля, но если этой сущностью является переменная, то вне модуля, где она определена, переменная доступна только на чтение.

После поездки в 1976-1977 гг. в лаборатории Xerox PARC, где Вирт вплотную познакомился с работами над проектом Alto, включая Smalltalk и Mesa, он принял решение значительно перелицевать свой язык Modula-2, во многом приблизив его к решениям языка Mesa (1974-1976) -- пожалуй, первого полноценного языка модульного программирования.

В языке Modula-2 (1977-1979) появились описательные/интерфейсные (definition module) и исполнительные (implementation module) модули. Были введены локальные модули. Был введен программный модуль (головная программа -- процесс ОС). Остальное наследие языка Modula в отношении модуля было практически полностью сохранено.

В языке Oberon (1987-1988) были изъяты за ненадобностью локальные модули, произошло синтаксическое слияние (точнее, это было в более поздней версии Оберона 1990 г.) интерфейсных и исполнительных модулей, но с сохранением семантического расхождения между ними (интерфейсный модуль в Обероне строится автоматически по маркировке сущностей признаками экспорта -- звездочками). Программный модуль также прекратил свое существование -- вместо него роль процесса выполнял все тот же единый Оберон-модуль. Он стал единицей загрузки-выгрузки. При этом любая процедура без параметров, экспортируемая из модуля, становилась командой ОС (ключевая особенность ОС Oberon). Экспортируемые процедуры без параметров стали точками входов модулей-процессов. Вирт довел идею модуля до самой границы компонента. Чтобы превратить модуль в компонент, остается только выполнить "протокольные соглашения" по инфраструктурной обвязке, в остальном модули Оберона -- практически готовые к употреблению компоненты.

В линии Modula-2/Oberon модули рассматриваются и как единицы раздельной компиляции (separate compilation), которая противопоставляется традиционной независимой (independent compilation). Раздельная компиляция позволяет обеспечивать трансляцию модулей без доступа к исходной или бинарной форме импортируемых модулей, от них берутся только интерфейсы (в исходном или бинарном виде), при этом осуществляется полный контроль типов и версионной рассинхронизации между интерфейсом и его реализацией. Линковка (динамическая) модулей осуществляется на фундаменте раздельной компиляции.

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

P.S. Дополнительную информацию о языке Modula (не Modula-2) можно посмотреть тут:
http://www.delphikingdom.com/asp/talktopic.asp?ID=285&ref=msg&msg=3870
(сообщение 3864)

Ответ на »сообщение 3438« (Илья Ермаков)
___________________________

То, что вы называете "модульностью" - на самом деле правильнее называть "пакетностью".


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

Ответ на »сообщение 3436« (Jack Of Shadows)
___________________________

Ответ на »сообщение 3435« (AVC)
Вот там и реализация стандартной модульная системы мощная. С ней и сравнивайте.

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

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

Ответ на »сообщение 3436« (Jack Of Shadows)
___________________________

>>>Не понял. Какое отношение имеет присваивание к отсутствию или наличию модульности ?

Я уже поднимал этот вопрос в »сообщение 3279«.
А Ваш вопрос следует адресовать авторам SICP.