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

_>>Да, естественно my_equal_to неявно параметризуется (знакомое слово, не так ли?) указателем на оператор сравнения для нужного типа. И приблизительно так же работают внутренние механизмы, позволяющие функционировать Хаскелю. А в чём собственно проблема то? Или ты снова пытаешься подправить определения, так что бы они укладывались под твоё противоречивое мировоззрение? ) Изначально у нас было очевидное определение "единый код для всех типов", а небольшой спор был лишь на тему стоит ли тут учитывать только исходный код (на мой вкус только это и важно) или надо учитывать ещё и генерируемый для функции машинный код. Ну вот тут мы имеем пример с одинаковым для всех типов и исходным и машинным кодом, и теперь ты пытаешься добавить ещё какие-нибудь оговорки. )))
S>Я тут вижу только одну проблему. ЧТо ты в одном абзаце снчала говоришь что my_equal_to неявно параметризуется указателем на оператор сравнения для нужного типа, а потом утверждаешь что исходя из необходимости учета машинного кода, выходит что код одинаков. Однако, для разных типов выполняется разный машинный код, именно потому и есть необходимость в указании указателя на оператор сравнения.

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

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

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

_>>Ага, ага, только смотрим на этот код на Хаскеле:
_>>

_>>apply f a = f a
_>>f a = a + 1
_>>apply f 1   -- выполняется код сложения для Int
_>>apply f 1.0 -- выполняется код сложения для Float
_>>

_>>и видим, что следуя твое логике apply — это очевидный ad hoc. Ой. Вот уж действительно повод для криков. )
S>apply по моей логике — очевидный параметрический полиморфизм. Но apply f — это уже другая функция. И она ad hoc.

Где-то в моём примере объявлена или используется функция вида "g = apply f"? ) Не надо подобных дешёвых фокусов.

_>>Ну ка покажи где это было указано, что для проверки функции на принадлежность к одному из видов полиморфизма надо проверять не только тело самой функции (одно оно для всех типов или нет), но тела всех других функций, вызываемых из данной.
S>Про тела — не скажу. Но одинаковое поведение для разных типов требуется в TAPL (приведу ниже). А твоей my_equal_to очевидно не может обеспечить одинаковое поведение для разных типов. Нужен пример?

У my_equal_to абсолютно одинаковое поведение для всех типов — она вызывает (и это вся её деятельность) оператор равенства соответствующего типа.

_>>Очень даже получается. Потому что на низком уровне только ad hoc и существует. Соответственно если ты придерживаешься точки зрения, что надо проверять функции на полную глубину стека вызова, то мы абсолютно всегда найдём какой-то ad hoc.
S>Зачем? это же очевидно легко бьется.
S>

S>Prelude> let myConst :: t -> Int ; myConst t = 0
S>Prelude> :t myConst
S>myConst :: t -> Int
S>

S>Найди здесь хоть какой-то ad hoc. Или нам с тобой надо будет еще рулиться за понимание сочетания слов "абсолютно всегда"?

А, ну да) Остроумно. ))) И много таких функций встречается в твоих приложениях? )

_>>Ну вообще говоря мнение из внутреннего мирка Хаскеля при обсуждение глобальных вопросов для меня вообще не аргумент. Но в данном конкретном случае материалы по указанной тобой ссылке опять же противоречит другим твоим позициям. Потому как согласно им apply является параметрически полиморфной. А согласно твоей "кричащей" позиции — нет. )
S>ты как-то не поймешь все мою позицию, пытаешься выдвигать за меня тезисы. Нет у меня кричащей позиции о том что apply ad hoc. Это ты подставить меня желаешь зачем-то. apply параметрически полиморфна (точка). ad hoc полиморфна apply f, а не apply. Надо объяснять что это разные функции?

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

_>>Это согласно определению из вики Хаскеля. А по твоей позиции (что надо учитывать весь стек вызова) как раз получается ad hoc.
S>Вообще не получается. Это твои выдумки. Весь стек вызовов функции apply заканчивается на возврате функции, которой ты подашь int или float. И ты либо об этом знаешь, либо никудышный знаток Хаскеля.


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

https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/HaskellExecution/FunctionCalls — на вот, просвещайся как обстоят дела в реальности, чтобы не писать больше подобных глупостей.

_>>А я разве где-то писал, что согласен с подобными критериями? ) Данная функция выглядит одинаково для всех типов и в исходных и в машинных кодах. Покажи что конкретно по твоему не укладывается в ней в цитируемое тобой же определение параметрического полиморфизма (например из TAPL).
S>Ок, давай я его процитирую, что бы под рукой было.
S>

S>Parametric polymorphism, the topic of this chapter, allows a single piece of code to be typed “generically,” using variables in place of actual types, and then instantiated with particular types as needed. Parametric definitions are uniform: all of their instances behave the same.

S>Вот поведение-то и не укаладывается, т.к. оно различное для разных типов. Так же как и различен набор машинных кодов, которые выполнятся (на всю глубину стека) при инстанциации разными типами.

Так где тут указано про "всю глубину стека"?

S>А вот в это определение:
S>

S>Ad-hoc polymorphism, by contrast, allows a polymorphic value to exhibit different behaviors when “viewed” at different types.

S>твоя my_equal_to абсолютно и полностью укладывается.

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

S>Чую, ответишь что я и Пирса в свою секту перетянул.

У меня к его определениям никаких особых возражений нет. Более того, это его абстрактное piece of code как раз в точности соответствует моей формулировке и позволяет сделать два отдельных применения: на уровне исходных кодов (на мой вкус только это и важно) и на уровне машинных кодов (вообще не важно, но можно тоже поанализоровать для развлечения).