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

Код пишется не для компилятора а для человека.

Во-первых, не код (code), а исходный текст (source). Я понимаю желание американцев все упрощать до неузнавания. Но не надо за ними вторить глупости. Отсюда, кстати, и пошло пренебрежительное "кодер" по отношению к программистам. Исторически код -- это объектный или машинный код (понимается исключительно программой/машиной). А исходный текст -- он и для человека, и для машины (программы). В этом терминологическая разница.

Во-вторых, исходный текст подразумевает два разных режима обработки (что для человека, что для машины): синтез и анализ. Синтезирует обычно человек (хотя может и машина). Анализируют оба.

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

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

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

Ответ на »сообщение 3723« (Руслан Богатырев)
___________________________
Слова ради слов. Императивный язык на то и императивен.
В смысле на то и императивен чтобы ставить подножки в коде в виде неявного и неочевидного из кода изменения состояния переменных ?
(Надеюсь что с этим вопросом я упаду в ваших глазах еще ниже)

Ответ на »сообщение 3722« (Руслан Богатырев)
___________________________
а при фактических "квалификация" передачи не делается (она однозначна для компилятора и не требует его домысливания).
Код пишется не для компилятора а для человека.
Глядя на такую функцию человек понятия не имеет что одна из переменных может после передачи ее в функцию вдруг  поменять значение.
Вот где код трудно понять "с листа".

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

Вот тут надо было быть последовательным и принципиальным до конца.

Джек, чем дальше, тем Вы все ниже падаете в моих глазах. Слова ради слов. Императивный язык на то и императивен. Это другое дерево. Не ФП.

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

Тем не менее, в Обероне перед фактическим параметром-переменной VAR ставить не нужно. Это недостаток Оберона, или между этими ситуациями всё же есть принципиальная разница, которую я пока не вижу?

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

В классическом Обероне для формальных параметров используется схема Модулы-2 (VAR для передачи по ссылке, ничего -- для передачи по значению). Для передачи по имени (как в Алголе) используются процедурные переменные. В том же классическом Паскаля (1970) была более навороченная схема: перед именем формального параметра указывался конкретно вид сущности -- const, var, function, procedure.

В Компонентном Паскале взяли схему, близкую к Аде: VAR, IN и OUT. Т.е. для передачи по значению не указывается ничего (режим всегда in), а при передачи по ссылке "квалифицируется" характер передачи -- in, out или inout. Но это все относится к формальным параметрам, а при фактических "квалификация" передачи не делается (она однозначна для компилятора и не требует его домысливания).

Ответ на »сообщение 3719« (Антон Григорьев)
___________________________
Это недостаток Оберона, или между этими ситуациями всё же есть принципиальная разница, которую я пока не вижу?
Огромная разница. И это большой недостаток оберона.
Обьясняю. Функция возвращает данные ТОЛЬКО одним единственным способом, через возвращаемый параметр.
То есть это то что программист от нее ОЖИДАЕТ.
Поэтому когда функция вдруг меняет один из передаваемых ей параметров - это удар в спину ничего не подозревающему программисту. Все точки в которых данные МОГУТ быть изменены должны быть ЯВНО помечены.
Иначе вас ждут неприятные сюрпризы. Вот тут надо было быть последовательным и принципиальным до конца.

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

А вот в Эрланге - ради бога можно и file.open :))

Все объясняется разной школой. Те, кто создавал Erlang, были сторонниками школы Вирта и Дейкстры. Всего лишь.

Ноги Erlang растут из EriPascal -- он вышел из экспериментов над средой PLEX (Programming Language for EXchange Switches) в компании Ericsson. Создавался как альтернатива языку CHILL (CCITT High Level Language).

Автор языка Бьерн Декер (Bjarne Dacker) писал, что идеи Erland и EriPascal вышли из виртовских языков: Паскаля, Модулы-2 и PL360. Да и личность самого Вирта сыграла здесь не последнюю роль. On my wall I have a framed photograph of myself presenting PASTEL for Niklaus Wirth. That was some experimental language that we were working on at the same time as he was working on Modula. I actually listened to his first lecture presenting Modula for his students in Zurich in hoch deutsch! Instead of PASTEL there came EriPascal but just imagine how beautiful manuals we could have printed!
http://www.erlang.org/pipermail/erlang-questions/2003-February/007354.html

Еще из его воспоминаний: I went to a Pascal conference in Southampton in 1977 and Brinch-Hansen described Concurrent Pascal. When asked what he thought of Modula (that Wirth just had brought out), he replied that you might do something clever but then "Claus" would come with the worked-through elegant version of it!

По мнению же Джо Армстронга, другим источником идей были работы Дейкстры: One other work which influenced Erlang was Dijkstra's idea of guarded commands - Dijkstra liked *every* alternative in a multi-way branch to have a guard.
http://www.erlang.org/pipermail/erlang-questions/2003-February/007325.html

В силу жизненных обстоятельств пришлось начать изучение C#. И столкнулся с такой особенностью этого языка: если формальный параметр объявлен как ref (аналог var в Паскале), то и перед фактическим параметром при вызове этой функции необходимо ставить ключевое слово ref. Что-то вроде такого:

void SomeFunc(ref int Param);
....

// Вызов
int i;
SomeFunc(ref i);

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

Ответ на »сообщение 3717« (Trurl)
___________________________
Сообщением "Unresolved overloading" ;-)

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

Ответ на »сообщение 3711« (Geniepro)
___________________________
>>>H: Чушь. Автоматический вывод типов нам поможет! :о))
Сообщением "Unresolved overloading" ;-)