Здравствуйте, samius, Вы писали:

_>>1. Считаешь ли ты, что при анализе вида полиморфизма некой функции, достаточно смотреть только на её исходный код и всё?
S>Нет.
_>>2. Если на первый вопрос ответ отрицательный, то сформулируй чётко и подробно (опиши алгоритм) что по твоему надо проанализировать ещё.
S>Ты забыл сказать "пожалуйста". Но, я, пожалуй, отвечу таки. Из определения TAPL следует необходимость анализа поведения, будет ли оно разным для разных типов. По Strachey 67 становится ясно что нужно анализировать, будет ли выполняться различный код для каждого типа.

Тогда 3 уточняющих вопрос:
1. Т.е. у тебя нет разделения на полиморфизм на уровне исходного и машинного кода и ты всегда выводишь для функции объединение обоих критериев (я предпочитаю рассмотреть отдельно на каждом уровне и озвучивать для каждой функции два отдельных результата)?
2. Т.е. под фразой "будет ли выполняться различный код для каждого типа" ты подразумеваешь сравнение машинного кода функции, генерируемого для каждого типа или же что-то другое?
3. Если в пункте 2, ты говорил про машинный код, то подразумеваешь только сравнение тела функции или же добавляешь к этому ещё и сравнение машинного кода всех других функций из стека вызова нашей?

S>>>http://rsdn.org/forum/flame.comp/6676499.1

Автор: samius
Дата: 24.01.17

S>>>http://rsdn.org/forum/flame.comp/6677933.1

Автор: samius
Дата: 25.01.17

_>>В данные цитатах нет ни одного слова про подобное. Или у тебя своё особое понимание и английского языка?
S>Особое от твоего — точно. Я вот в этих определениях не увидел ничего про "тело функции". А ты — увидел.

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

_>>И? ) Тебе что-то не нравится? )
S>То, что различный код для equal_to выполняется, но ты уперся "в тело".

На низком уровне различный код исполняется всегда (хотя бы потому что ЦПУ у нас по сути ad hoc). И соответственно если следовать твоей логике, то само понятие параметрического полиморфизма теряет смысл для подавляющей части реального кода.

_>>Повторяю ещё раз: у меня лично вообще другая позиция на это всё (которую я изложил ещё в изначальном сообщение), в которой никаких внутренних противоречий нет. А здесь я беру твою позицию и демонстрирую её противоречия. Т.е. получается что ФВП уже являются неким исключением в твоей картине мира? )))
S>Да, у твоей позиции внутренних противоречий нет, но есть противоречия с другими определениями и способами классификации. Именно их (противоречия) мы и обсуждаем.
S>Ничего не получается такого с ФВП. apply параметрически полиморфна.

Это согласно моей точки зрения. И так же согласно твоим отдельным заявлениям. А теперь (когда ты конкретизируешь те 3 пункта в начале сообщения) мы посмотрим получается ли тоже самое из твоего определения критериев. И соответственно если не получится, то будем в очередной раз громко смеяться.

_>>Ну и насчёт чистоты... Если уж ты заикнулся про это, то должен знать, что в том же Хаскеле есть известные механизмы для изоляции "грязного кода", так что в определённых случаях он вполне может располагаться внутри чистой функции. Как раз очень хорошая аналогия наблюдается... )))
S>Аналогия чему? Ты хочешь сказать что map стала перманентно грязной от того что ты в нее смог однажды подсунуть изолированную грязную функцию?

Ты снова путаешь свои взгляды и мои?) В моих как раз на поведение apply ничего не влияет. )

А по поводу аналогии очевидно же. Возьмём мой пример my_equal_to на C++. Он использует некий тип eq, который как раз и осуществляет изоляцию ad hoc кода в себе, так что вызов его оператора равенства из my_equal_to получается параметрически полиморфным (такой оператор опять же ровно один для всех типов, и в исходных кодах и в машинных).

_>>Я так понимаю, что тебе показалось, что ты тут обнаружил какое-то противоречие в моих словах? ) Но я что-то в упор его не вижу. Расшифруй в деталях, что конкретно тебе тут не нравится.
S>Пожалуйста:
S>Один раз ты сравнил поведения двух различных функций, у которых различная реализация на уровне машинных кодов. При этом сказал что поведение будет "как у", т.е. одинаковое. Я полагаю, ты интуитивно использовал procedural abstraction.

Непонятно зачем ты постоянно приплетаешь данный термин из области методологии разработки ПО. У нас же вроде как чисто техническая дискуссия.

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

S>

S>Функции apply f не существует в природе, пока ты не определил где-то что-то вроде g=apply f. В этом случае на уровне машинных кодов появится отдельная функция с поведение как у apply f, но при этом она будет всего лишь обёрткой над apply.

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

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

S>

S>>твоя my_equal_to абсолютно и полностью укладывается.
S>Не укладывается, т.к. поведение абсолютно одинаковое: вызов оператора равенства для соответствующего типа. )

S>То есть у тебя слово "поведение" вызывает некий диссонанс, что может объяснять проблемы понимания определений, использующих слово "поведение".
S>И если в определениях использовать твой первый вариант (процедурной абтракции), то как раз и выйдет, что функция my_equal_to ведет себя по разному для разных типов, а значит вписывается в ad-hoc.
S>Но ты почему-то уперся и используешь второе понятие — поведение исполнителя (через вызов оператора).

С трудом понял о чём ты говоришь, настолько странно ты используешь (а точнее чаще вообще не используешь) терминологию нашей отрасли. По сути ты здесь хочешь предложить включать во внешний контракт функции my_equal_to не только тот факт, что она производит сравнение полиморфных типов, но и то, что она это делает обязательно с помощью вызовов операторов равенства соответствующих типов. Но это на самом деле не верно. Потому как в реальности происходит вызов не этих операторов, а оператора равенства типа eq (что легко проверить чуть поменяв этот тип так, чтобы он перестал захватывать и использовать пользовательские операторы). Вот данный факт (про использования оператора равенства eq) вполне возможно стоит рассматривать как часть внешнего контракта my_equal_to. Однако он явно не будет свидетельствовать об ad hoc природе my_equal_to.

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

S>Хотя, заметь! Сам ты используешь оба смысла слова "поведение", причем, даже в одном посте, и наверняка с разницей не более пары минут.

Вообще то мне известно всего одно значение слова "поведение" (причём и оно то не "компьютерное"), так что использовать какие-то два его смысла я бы не смог физически. )