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

В языке Оберон (дальнейшие рассуждения справедливы и для КП) есть 5 видов сущностей:
1) типы;
2) константы;
3) переменные;
4) процедуры (функции);
5) модули.

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

Для использования внешних сущностей внутри модуля требуется осуществлять импорт. Различают:
1) неквалифицирующий импорт (без указания имени модуля при обращении к внешней сущности);
2) квалифицирующий импорт (указание имени модуля перед внешней сущностью).

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

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

Существуют три варианта схем импорта сущностей:
1) cтрогая (только квалифицирующий импорт, Оберон);
2) смешанная (как квалифицирующий, так и неквалифицирующий импорт, Модула-2, Хаскель);
3) упрощенная (только неквалифицирующий импорт).

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

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

Межмодульные связи в Обероне формируется на основе интерфейсов (DEFINITION) и представленных в них отношений экспорта-импорта.

Чтобы использовать любую внешнюю сущность, программисту требуется:
1) указать источник заимствования (имя импортируемого модуля);
2) указать имя заимствованной сущности в месте ее использования.

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

Уточню, реальный "поставщик" и/или "потребитель" услуг может меняться (в runtime, в том числе) в зависимости, например, от состояния системы. А разработчик модуля ни о самой системе, ни о ее состояниях... знать не должен.

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

В теории систем есть понятия "сильных" и "слабых" связей. "Сильные" связи образуют элементы системы, а "слабые" связи соединяют элементы.

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

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

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

ФП сегодня как никогда выгодно и модно:

Надо же, какое у Вас предубеждение против ФП. Именно предубеждение, иначе и не скажешь... 8-о

Мне нет надобности стараться. Просто хочется понять, есть ли теоретически такие ситуации, чтобы о них знать и учитывать, как потенциальный источник ошибки. Если нет -- так и скажите. Если есть -- было бы интересно узнать.

Насколько я знаю, корректность алгоритмов вывода типов для Хаскелла доказана математически. Если возникнут какие-то баги (а баги могут быть везде), то они будут исправлены.

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

Вам придётся постараться, что бы суметь обмануть транслятор и его вывод типов.

Мне нет надобности стараться. Просто хочется понять, есть ли теоретически такие ситуации, чтобы о них знать и учитывать, как потенциальный источник ошибки. Если нет -- так и скажите. Если есть -- было бы интересно узнать.

Ответ на »сообщение 3853« (Владимир Лось)
___________________________

Семь лет мы тут воду в ступе толчём, а где результаты?

Мы долго запрягаем, но быстро ездим и сильно тормозим :)

Душкин вон напечатал книгу по Хаскелю. Книжка немного сумбурная, слабая, оформлена - из рук вон... Но посмотрите на эффект, сколько дискуссий возникло.

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

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

Тут нечему удивляться.

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

А здесь - что? Тем более при вашей лично, Руслан, кипучей деятельности, много- и связнословии и возможности контакта с "прессой"?

Упрек по адресу. Что делать -- будет потихоньку исправляться.

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

А В Хаскеле есть вероятность путаницы?

Вам придётся постараться, что бы суметь обмануть транслятор и его вывод типов.

Имена модулей для указания указания функций и типов использовать нельзя - транслятор не позволит.
Имена типов выполнять как функции или конструктора типов тоже нельзя.
Функции возвращать значения-типы не могут.

Человек, конечно, может запутаться и в трёх соснах, но как-то трудно представить путанницу между именами модулей, типов и конструкторов типов в Хаскелле...

Ответ на »сообщение 3853« (Владимир Лось)
___________________________
Надо вопросы задавать товарищу Свердлову из ВПГУ.

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

Ну как сказать? Для удобства... Опеределяете модуль Tree, логично в нём разместить тип данных Tree, а один из конструкторов этого типа назвать тоже Tree - меньше лишних имён, меньше головной боли.
Хотя с непривычки кажется странным для нехаскеллеров, конечно... ;о)

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

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

Ответ на »сообщение 3839« (Димыч)
___________________________

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

Давайте разделим конкуренцию на три вида:
1. Технологическая (технологические возможности, предоставляемые языком)
2. Инфраструктурная (инструменты, проекты, книги, кадры и т.п.)
3. Рыночная

Говоря о конкуренции Оберона с Си в сфере системного программирования, я имел в виду лишь технологическую конкуренцию.

И тем не менее, Оберон дает "глоток свежего воздуха"

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

Встает во весь рост проблема нехватки знаний по проектированию и опыта декомпозиции. Наблюдая за собой и за другими, могу сказать, что знакомство с Обероном надо сопровождать знакомством с работами Parnas'a, МакКоннела и прочими работами именно по инженерному подходу к разработке программ. Сейчас же наблюдается каша в головах, поэтому отчасти и трудно идет продвижение Оберона.

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

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

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

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

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

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

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

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

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

Если эти заготовки просто облегчение copy/paste, это одно. А если они делают "дорожную разметку" и даже сложную "транспортную развязку" (заранее продуманную и отлаженную), причем с последующим контролем от возможных отклонений, то это реальная помощь.

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

Это не рекомендации, а синтаксис языка.

Похоже, Вы правы. Хотелось бы понять, сколь это важно для языка. В Обероне мне как-то тяжело представить ситуацию, когда, как бы ни записывалась сущность, можно ненароком спутать переменную с типом. Кроме разве что приведения типа -- охранника типа (typeguard). А В Хаскеле есть вероятность путаницы?

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

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

При импорте можно переименовывать импортируемые модули, так что перенастраивать связи не так уж и трудно...


Уточню, реальный "поставщик" и/или "потребитель" услуг может меняться (в runtime, в том числе) в зависимости, например, от состояния системы. А разработчик модуля ни о самой системе, ни о ее состояниях... знать не должен.

А тут для Оберонов есть "реверсированный" импорт... :о)