Ответ на »сообщение 3703« (Руслан Богатырев)
___________________________
Думаю, самое время начинать называть вещи своими именами и перестать щадить чье-то самолюбие. Ваша фраза -- элементарная ложь.
Talk about hypocrites. Для некоторых "более равных" функций значит можно исключения делать ?

Ответ на »сообщение 3704« (Trurl)
___________________________
Кстати, зря. Вполне естественно смотрелись бы List.map, Set.map, Array.map..
Полиморфизм вещь удобная.
А то ведь и арифметические операторы можно явно квалифицировать как в OCAML. Отдельно "+" для целых чисел и "+." для real.
Только ведь большинство взвоют от такой "естественности".

Ответ на »сообщение 3699« (Geniepro)
___________________________
Ну и кто тут говорил о лукавстве? ;-) Всякие там primPlusInt не учитываем?
И зачем формально включать в Prelude такие вещи, как [a], если они намертво зашиты в язык?

>>> в Хаскелле никому в голову не приходит квалифицировать циклические функции map, foldr...
Кстати, зря. Вполне естественно смотрелись бы List.map, Set.map, Array.map..
В частности, Set.map ничуть не хуже чем mapSet.

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

А map foldl, filter, которые и есть адекватная замена тем же операторам цикла в хаскеле, требуете квалифицировать.

Думаю, самое время начинать называть вещи своими именами и перестать щадить чье-то самолюбие. Ваша фраза -- элементарная ложь. См. »сообщение 3656«.

Ответ на »сообщение 3700« (AVC)
___________________________
2) Линковщик выбирает нужный вариант "эвристически", например, как в Турбо Паскале (и Delphi?) -- из модуля-кандидата, упомянутого в списке последним.
А где гарантия, что это правильный выбор?
Гарантия проста - квалифицируйте. Вот только зачем ОБЯЗАТЕЛЬНО ВСЕ квалифицировать ?
Или у вас в системе у каждой функции свой двойник с одинаковым именем, списком и типами параметров и возвращаемым значением ?
Квалифицировать приходится всем. И в дельфях и в том же хаскеле. Вот только экстремизм в подходе непрактичен.
Квалифицировать всегда только потому что в одном из ста случаев может случиться неявная подмена, это экстремизм, то есть доведение до крайнего случая. Любителей экстремизма всегда хватает, но большинство вас не поймут.
GeniePro тут уже приводил пример с встроенными операторами оберона. Вы же их не квалифицируете.
А map foldl, filter, которые и есть адекватная замена тем же операторам цикла в хаскеле, требуете квалифицировать.
Почему ? Ах это не операторы а функции.
Потом опять же - костылями вы не пользуетесь. Печатаете код на бумагу или с сайта DelphiKingdom код читаете.
Потом, глядя на название функции
myFile := OpenFile("test.txt", ReadWrite)
вы не можете понять что же она делает.
Не можете понять ни из названия функции, ни из передаваемых ей параметров, ни из возвращаемого значения, ни из контекста применения. Вам обязательно надо видеть ИМЯ МОДУЛЯ.

myFile := Files.OpenFile("test.txt", ReadWrite);

Так наверное лучше, да ? Сразу понятно теперь что делает функция OpenFile, что означают параметры "test.txt", ReadWrite, и почему в контексте кода строчкой дальше написано myFile.Read;

Я удивляюсь как вы без имени модуля понимаете что означают for, while, repeat !!
Ведь понять что означает map, foldl, filter без имени модуля вы кажется не в состоянии.

Вам нужны костыли в виде обязательных имен модулей перед КАЖДОЙ (!!!) функцией, перед КАЖДЫМ обьектом.
Послушайте, а локальные для модуля обьекты и функции вы тоже квалифицируете ?
типа ThisModule.myLocalFunction
А то ведь не ровен час, кто нибудь в одном из импортируемых вами модулей ДИНАМИЧЕСКИ возьмет и введет функцию с точно таким же названием. Вот конфуз выйдет.

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

>>>А где гарантия, что это правильный выбор?

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

Пусть мы импортируем 2 модуля: M1 и M2, в каждом из них определены процедуры A() и B().
И надо же такому случиться, что нам потребовалась процедура A() из модуля M1, а процедура B() из модуля M2.
Здесь, как ни крути, без квалифицирующего импорта не обойтись.
Конечно, этот последний пример довольно искусственный (хотя кто знает?).
Главное же в квалифицирующем импорте -- уберечь нас от неприятных неожиданностей.
Не слишком логично, IMHO, использовать строгий язык (Паскаль), а в местах межмодульных соединений от этой строгости вдруг отказываться и полагаться на "авось". :)

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


Линковка происходит динамически при загрузке модуля.
И к какой FindClose (если взять пример Антона Григорьева) прикажете на ходу линковаться?


Возможно, даже это не вполне понятно.
Попробую объяснить подробнее.
В Обероне клиент не требует перекомпиляции, если изменения в модуле оставили интерфейс в неизменности или даже расширили его.
Представим себе, что Вы пользовались процедурой FindClose, и все было замечательно. :)
Но случилось так, что разработчики одного из импортируемых Вами модулей решили расширить его функциональность и тоже завели себе процедуру FindClose.
Тогда у линкующего загрузчика два варианта.
1) При загрузке модуля подать сигнал тревоги и отказаться загружать "двусмысленную ерунду". :)
Проблема в том, что у измененного модуля могло быть огромное число клиентов, исходный код может отсутствовать и т.д.
2) Линковщик выбирает нужный вариант "эвристически", например, как в Турбо Паскале (и Delphi?) -- из модуля-кандидата, упомянутого в списке последним.
А где гарантия, что это правильный выбор?

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

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

Да именно тем, что это не "стандартные процедуры", а именно часть языка. Операции, записываемые в префиксной форме со скобками - И ВСЕ. И их использование - это не вызов функции, а просто монолитная часть выражения.

Хм, ну тогда в таких языках, как Хаскелл, вообще нет никаких стандартных функций и операций. +, -, *, / и пр., циклические операции над списками (map, foldr, foldl, take, drop и пр.) - всего этого нет в виде языковых конструкций. Всё это определено как методы стандартных классов и стандартные функции.

А языковые конструкции - это всего лишь межмодульное взаимодействие (импорт/экспорт), выражение сопоставления по образцу (case of), условное выражение (if then else), конструкция монадического программирования (do), конструкции разграничения пространств имён (let in и where)... И всё!

Интересно, пришло бы в голову оберонщикам квалифицировать имена арифметических операций?
В Хаскелле такое вполне возможно, только хаскеллерам в голову даже не приходит.
Точно так же как в Обероне никто не квалифицирует операторы циклов, в Хаскелле никому в голову не приходит квалифицировать циклические функции map, foldr... Хотя в F# такие функции таки выделены в модуль List и выглядят типа List.map... :о))

Обероновский синтаксический сахар в Хаскелле вынесен в стандартную библиотеку Prelude.

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

Хотите чертеж - любая современная CAD система может представить сложнейшие объекты в 3D и позволяет поворачивать, рассекать, делать невидимыми части и т.д.; попробуйте доказать конструктору, что это костыли и независимый от компьютера бумажный чертеж гораздо прогрессивнее. Сейчас уже прораб на стройке предпочитает работать с ноутбуком, а не с бумажной простыней. А Вы отказываете в этом программисту.

Еще бы придумали, что я предлагаю программировать на счетах. :)
Я уже говорил, что IDE (в определенном контексте беседы, а не вообще!) был назван костылем не потому, что в нем есть удобства, а потому, что в языке (и следовательно в СП в целом) остались нерешенные важные проблемы, которые IDE как бы "прикрывает".
Приводились примеры проблем, не только на далеком от нас C#, но и на Турбо Паскале (Trurl) и на Delphi (Антон Григорьев).
Т.е. то, что проблемы есть, это факт.
И потому Ваши замечательные метафоры, IMHO, не по делу.
А чтобы наше отношение к этой проблеме стало нагляднее, рассмотрим ту же ситуацию, как она выглядела бы для Оберона, если бы не было квалификации импорта.
Оберон-система (в т.ч. многие Оберон-программы, работающие под виндами) в процессе работы может менять свой состав, добавлять новые модули и, иногда, удалять старые, "ненужные". :)
Линковка происходит динамически при загрузке модуля.
И к какой FindClose (если взять пример Антона Григорьева) прикажете на ходу линковаться?
Вы действительно полагаете, что программная система (особенно, конечно, динамическая) в условиях такой неопределенности может быть надежной?

Ответ на »сообщение 3691« (AVC)
___________________________
>>>Вообразите себе чертеж, в котором надо было бы все время щелкать мышкой, чтобы узнать необходимые технические сведения.
Например, Google Earth - гораздо удобнее атласа, но без компьютера, интернете и софта не работает.
Хотите чертеж - любая современная CAD система может представить сложнейшие объекты в 3D и позволяет поворачивать, рассекать, делать невидимыми части и т.д.; попробуйте доказать конструктору, что это костыли и независимый от компьютера бумажный чертеж гораздо прогрессивнее. Сейчас уже прораб на стройке предпочитает работать с ноутбуком, а не с бумажной простыней. А Вы отказываете в этом программисту.
Современная система программирования состоит из языка с его синтаксисом и стандартными библиотеками, среды исполнения и IDE. Считать одну систему лучше другой на основании того, что функции этих подсистем распределены по другому, вплоть до полного поглащения нестоит.
"Мы можем обойтись без IDE!" Ну и что?
Я могу обойтись много без чего, включая интернет. Но не хочу.
Ручной инструмент много лучше электрического, если электричество недоступно :)
И много хуже, если электричество есть.