Сообщение Re[36]: «Собаку съел» от 29.01.2017 14:11
Изменено 29.01.2017 14:44 alex_public
Re[36]: «Собаку съел»
Здравствуйте, samius, Вы писали:
_>>В смысле не согласен? Машинный код одинаков для всех типов с точностью до бита (эту функции в отличие от шаблонной можно скомпилировать в отдельный бинарный модуль). Это просто факт, с которым ничего нельзя поделать.
S>Машинный код сравнения двух значений не может быть независимым от типов этих значений. Эти значения просто нельзя начинать сравнивать, не зная их тип. Значит, если код твоей функции от типов не зависит, то он должен принять нечто, что позволит косвенно перейти к специализации сравнения. Классы типов хаскеля — это и есть эта косвенность.
S>А раз есть косвенность, значит есть и зависимость от специализации. А значит — ad hoc.
Да, естественно my_equal_to неявно параметризуется (знакомое слово, не так ли?
) указателем на оператор сравнения для нужного типа. И приблизительно так же работают внутренние механизмы, позволяющие функционировать Хаскелю. А в чём собственно проблема то? Или ты снова пытаешься подправить определения, так что бы они укладывались под твоё противоречивое мировоззрение? ) Изначально у нас было очевидное определение "единый код для всех типов", а небольшой спор был лишь на тему стоит ли тут учитывать только исходный код (на мой вкус только это и важно) или надо учитывать ещё и генерируемый для функции машинный код. Ну вот тут мы имеем пример с одинаковым для всех типов и исходным и машинным кодом, и теперь ты пытаешься добавить ещё какие-нибудь оговорки. )))
_>>Если же ты снова намекаешь на то, что данная реализация функции определена не для всех возможных типов (а только для имеющих оператор равенства), то это ничего не меняет. Потому что только для таких типов эта функция и будет использоваться — других вариантов (которые теоретически могли бы создать тот самый ad hoc через перегрузку) не будет в принципе.
S>Но для тех типов будет выполнен разный код сравнения, специальный для каждого типа? Я не про верхнюю функцию я про именно самый низкий уровень сравнения. Если разный — значит функция верхнего уровня, использующая эти разные коды — ad hoc. И я тут не намекаю уже. КРИЧУ!
Ага, ага, только смотрим на этот код на Хаскеле:
и видим, что следуя твое логике apply — это очевидный ad hoc. Ой. Вот уж действительно повод для криков. )
_>>Естественно разные, но это всё будет происходить не в теле функции my_equal_to, так что не имеет к ней отношения. Если же ты будешь настаивать в своём определение на учёт внутреннего устройства ещё и всех других функций (вызываемых из обсуждаемой), то тогда у тебя автоматически получится, что вокруг абсолютно всё ad hoc полиморфизм, а параметрического не существует вовсе (потому что на самом низком уровне всё ad hoc).
S>1) я не знаю, почему ты определение называешь моим, оно везде. А вот твое я нигде не нашел более (а источник ты не указал).
Ну ка покажи где это было указано, что для проверки функции на принадлежность к одному из видов полиморфизма надо проверять не только тело самой функции (одно оно для всех типов или нет), но тела всех других функций, вызываемых из данной.
S>2) нет, не получается автоматически. Ты передергиваешь.
Очень даже получается. Потому что на низком уровне только ad hoc и существует. Соответственно если ты придерживаешься точки зрения, что надо проверять функции на полную глубину стека вызова, то мы абсолютно всегда найдём какой-то ad hoc.
S>Разреши, я тебе подскажу лайфках. Есть такая страничка https://wiki.haskell.org/Polymorphism и в частности https://wiki.haskell.org/Polymorphism#Ad-hoc_polymorphism.
S>Там написано, какие функции в Хаскеле параметрически (абсолютно) полиморфны, а какие — ad hoc.
S>И на тот случай, если ты не станешь читать (а vdimas не стал), я процитирую оттуда параграф (vdimas-у уже цитировал, но ты ведь не читаешь мои ответы ему).
S>
Ну вообще говоря мнение из внутреннего мирка Хаскеля при обсуждение глобальных вопросов для меня вообще не аргумент. Но в данном конкретном случае материалы по указанной тобой ссылке опять же противоречит другим твоим позициям. Потому как согласно им apply является параметрически полиморфной. А согласно твоей "кричащей" позиции — нет. )
_>>Более того, при таком подходе у тебя возникает противоречие с собственными же предыдущими утверждениями. Например ты признал что обсуждаемая ранее функция apply (в Хаскеле) — это чистый параметрический полиморфизм без всяких оговорок. Но ведь в том примере в зависимости от типа второго параметра apply (int или float) выполнялся разный код (если смотреть на весь стек вызова, а не только на само тело apply). Т.е. по твоему подходу выше та apply — это тоже ad hoc.
S>
S>Видишь? вовсе не ad hoc.
Это согласно определению из вики Хаскеля. А по твоей позиции (что надо учитывать весь стек вызова) как раз получается ad hoc.
_>>Похоже что ты не смотря на готовность привести различные цитаты других специалистов так и не сумел сформировать у себя в голове непротиворечивое определение для данного явления.
S>Вовсе нет. То что оно противоречит с твоими убеждениями (и vdimas-а тоже) — не беда вовсе. Для меня важнее что оно не противоречит с классикой, википедией и даже хаскельвики.
Очень даже противоречит. Просто ты сейчас пытаешься сделать банальнейшую манипуляцию с двойными стандартами, чтобы скрыть это. Для проверки C++ когда ты предлагаешь использовать одни критерии (весь оригинальные, с анализом всего стека вызова), а для проверки кода на Хаскеле (а конкретно функции apply) ты предлагаешь использовать совсем другие критерии (которые ты взял из вики Хаскеля, о наличие Eq a). Подобные дешёвые фокусы совсем не подходят для приличной дискуссии...
_>>Аналогом my_equal_to в мире Хаскеля будет такой очевидный код:
_>>
_>>Причём данные реализации (C++ и Хаскель) не только выглядят одинаково на уровне исходного кода (и даже имеют по сути одинаковые типы), но и будут крайне похожи на уровне машинного.
S>тадам....
S>
А я разве где-то писал, что согласен с подобными критериями? ) Данная функция выглядит одинаково для всех типов и в исходных и в машинных кодах. Покажи что конкретно по твоему не укладывается в ней в цитируемое тобой же определение параметрического полиморфизма (например из TAPL).
_>>В смысле не согласен? Машинный код одинаков для всех типов с точностью до бита (эту функции в отличие от шаблонной можно скомпилировать в отдельный бинарный модуль). Это просто факт, с которым ничего нельзя поделать.
S>Машинный код сравнения двух значений не может быть независимым от типов этих значений. Эти значения просто нельзя начинать сравнивать, не зная их тип. Значит, если код твоей функции от типов не зависит, то он должен принять нечто, что позволит косвенно перейти к специализации сравнения. Классы типов хаскеля — это и есть эта косвенность.
S>А раз есть косвенность, значит есть и зависимость от специализации. А значит — ad hoc.
Да, естественно my_equal_to неявно параметризуется (знакомое слово, не так ли?
) указателем на оператор сравнения для нужного типа. И приблизительно так же работают внутренние механизмы, позволяющие функционировать Хаскелю. А в чём собственно проблема то? Или ты снова пытаешься подправить определения, так что бы они укладывались под твоё противоречивое мировоззрение? ) Изначально у нас было очевидное определение "единый код для всех типов", а небольшой спор был лишь на тему стоит ли тут учитывать только исходный код (на мой вкус только это и важно) или надо учитывать ещё и генерируемый для функции машинный код. Ну вот тут мы имеем пример с одинаковым для всех типов и исходным и машинным кодом, и теперь ты пытаешься добавить ещё какие-нибудь оговорки. )))_>>Если же ты снова намекаешь на то, что данная реализация функции определена не для всех возможных типов (а только для имеющих оператор равенства), то это ничего не меняет. Потому что только для таких типов эта функция и будет использоваться — других вариантов (которые теоретически могли бы создать тот самый ad hoc через перегрузку) не будет в принципе.
S>Но для тех типов будет выполнен разный код сравнения, специальный для каждого типа? Я не про верхнюю функцию я про именно самый низкий уровень сравнения. Если разный — значит функция верхнего уровня, использующая эти разные коды — ad hoc. И я тут не намекаю уже. КРИЧУ!
Ага, ага, только смотрим на этот код на Хаскеле:
apply f a = f a
f a = a + 1
apply f 1 -- выполняется код сложения для Int
apply f 1.0 -- выполняется код сложения для Floatи видим, что следуя твое логике apply — это очевидный ad hoc. Ой. Вот уж действительно повод для криков. )
_>>Естественно разные, но это всё будет происходить не в теле функции my_equal_to, так что не имеет к ней отношения. Если же ты будешь настаивать в своём определение на учёт внутреннего устройства ещё и всех других функций (вызываемых из обсуждаемой), то тогда у тебя автоматически получится, что вокруг абсолютно всё ad hoc полиморфизм, а параметрического не существует вовсе (потому что на самом низком уровне всё ad hoc).
S>1) я не знаю, почему ты определение называешь моим, оно везде. А вот твое я нигде не нашел более (а источник ты не указал).
Ну ка покажи где это было указано, что для проверки функции на принадлежность к одному из видов полиморфизма надо проверять не только тело самой функции (одно оно для всех типов или нет), но тела всех других функций, вызываемых из данной.
S>2) нет, не получается автоматически. Ты передергиваешь.
Очень даже получается. Потому что на низком уровне только ad hoc и существует. Соответственно если ты придерживаешься точки зрения, что надо проверять функции на полную глубину стека вызова, то мы абсолютно всегда найдём какой-то ad hoc.
S>Разреши, я тебе подскажу лайфках. Есть такая страничка https://wiki.haskell.org/Polymorphism и в частности https://wiki.haskell.org/Polymorphism#Ad-hoc_polymorphism.
S>Там написано, какие функции в Хаскеле параметрически (абсолютно) полиморфны, а какие — ad hoc.
S>И на тот случай, если ты не станешь читать (а vdimas не стал), я процитирую оттуда параграф (vdimas-у уже цитировал, но ты ведь не читаешь мои ответы ему).
S>
S>Я не знаю, будешь ли ты спорить с хаскельвики, но эта цитата по-крайней мере является свидетельством того, что не я один придерживаюсь определения, авторство которого ты приписываешь мне. Если, конечно, я не подправил хаскельвики.S>You can recognise the presence of ad-hoc polymorphism by looking for constrained type variables: that is, variables that appear to the left of =>, like in elem :: (Eq a) => a -> [a] -> Bool. Note that lookup :: (Eq a) => a -> [(a,b)] -> Maybe b exhibits both parametric (in b) and ad-hoc (in a) polymorphism.
Ну вообще говоря мнение из внутреннего мирка Хаскеля при обсуждение глобальных вопросов для меня вообще не аргумент. Но в данном конкретном случае материалы по указанной тобой ссылке опять же противоречит другим твоим позициям. Потому как согласно им apply является параметрически полиморфной. А согласно твоей "кричащей" позиции — нет. )
_>>Более того, при таком подходе у тебя возникает противоречие с собственными же предыдущими утверждениями. Например ты признал что обсуждаемая ранее функция apply (в Хаскеле) — это чистый параметрический полиморфизм без всяких оговорок. Но ведь в том примере в зависимости от типа второго параметра apply (int или float) выполнялся разный код (если смотреть на весь стек вызова, а не только на само тело apply). Т.е. по твоему подходу выше та apply — это тоже ad hoc.
S>
S>Prelude> apply f a = f a
S>Prelude> :t apply
S>apply :: (t -> t1) -> t -> t1
S>S>Видишь? вовсе не ad hoc.
Это согласно определению из вики Хаскеля. А по твоей позиции (что надо учитывать весь стек вызова) как раз получается ad hoc.
_>>Похоже что ты не смотря на готовность привести различные цитаты других специалистов так и не сумел сформировать у себя в голове непротиворечивое определение для данного явления.
S>Вовсе нет. То что оно противоречит с твоими убеждениями (и vdimas-а тоже) — не беда вовсе. Для меня важнее что оно не противоречит с классикой, википедией и даже хаскельвики.
Очень даже противоречит. Просто ты сейчас пытаешься сделать банальнейшую манипуляцию с двойными стандартами, чтобы скрыть это. Для проверки C++ когда ты предлагаешь использовать одни критерии (весь оригинальные, с анализом всего стека вызова), а для проверки кода на Хаскеле (а конкретно функции apply) ты предлагаешь использовать совсем другие критерии (которые ты взял из вики Хаскеля, о наличие Eq a). Подобные дешёвые фокусы совсем не подходят для приличной дискуссии...
_>>Аналогом my_equal_to в мире Хаскеля будет такой очевидный код:
_>>
_>>my_equal_to a b = a==b
_>>_>>Причём данные реализации (C++ и Хаскель) не только выглядят одинаково на уровне исходного кода (и даже имеют по сути одинаковые типы), но и будут крайне похожи на уровне машинного.
S>тадам....
S>
S>ad hoc.S>Prelude> my_equal_to a b = a==b
S>Prelude> :t my_equal_to
S>my_equal_to :: Eq a => a -> a -> Bool
А я разве где-то писал, что согласен с подобными критериями? ) Данная функция выглядит одинаково для всех типов и в исходных и в машинных кодах. Покажи что конкретно по твоему не укладывается в ней в цитируемое тобой же определение параметрического полиморфизма (например из TAPL).
Re[36]: «Собаку съел»
Здравствуйте, samius, Вы писали:
_>>В смысле не согласен? Машинный код одинаков для всех типов с точностью до бита (эту функции в отличие от шаблонной можно скомпилировать в отдельный бинарный модуль). Это просто факт, с которым ничего нельзя поделать.
S>Машинный код сравнения двух значений не может быть независимым от типов этих значений. Эти значения просто нельзя начинать сравнивать, не зная их тип. Значит, если код твоей функции от типов не зависит, то он должен принять нечто, что позволит косвенно перейти к специализации сравнения. Классы типов хаскеля — это и есть эта косвенность.
S>А раз есть косвенность, значит есть и зависимость от специализации. А значит — ad hoc.
Да, естественно my_equal_to неявно параметризуется (знакомое слово, не так ли?) указателем на оператор сравнения для нужного типа. И приблизительно так же работают внутренние механизмы, позволяющие функционировать Хаскелю. А в чём собственно проблема то? Или ты снова пытаешься подправить определения, так что бы они укладывались под твоё противоречивое мировоззрение? ) Изначально у нас было очевидное определение "единый код для всех типов", а небольшой спор был лишь на тему стоит ли тут учитывать только исходный код (на мой вкус только это и важно) или надо учитывать ещё и генерируемый для функции машинный код. Ну вот тут мы имеем пример с одинаковым для всех типов и исходным и машинным кодом, и теперь ты пытаешься добавить ещё какие-нибудь оговорки. )))
_>>Если же ты снова намекаешь на то, что данная реализация функции определена не для всех возможных типов (а только для имеющих оператор равенства), то это ничего не меняет. Потому что только для таких типов эта функция и будет использоваться — других вариантов (которые теоретически могли бы создать тот самый ad hoc через перегрузку) не будет в принципе.
S>Но для тех типов будет выполнен разный код сравнения, специальный для каждого типа? Я не про верхнюю функцию я про именно самый низкий уровень сравнения. Если разный — значит функция верхнего уровня, использующая эти разные коды — ad hoc. И я тут не намекаю уже. КРИЧУ!
Ага, ага, только смотрим на этот код на Хаскеле:
и видим, что следуя твое логике apply — это очевидный ad hoc. Ой. Вот уж действительно повод для криков. )
_>>Естественно разные, но это всё будет происходить не в теле функции my_equal_to, так что не имеет к ней отношения. Если же ты будешь настаивать в своём определение на учёт внутреннего устройства ещё и всех других функций (вызываемых из обсуждаемой), то тогда у тебя автоматически получится, что вокруг абсолютно всё ad hoc полиморфизм, а параметрического не существует вовсе (потому что на самом низком уровне всё ad hoc).
S>1) я не знаю, почему ты определение называешь моим, оно везде. А вот твое я нигде не нашел более (а источник ты не указал).
Ну ка покажи где это было указано, что для проверки функции на принадлежность к одному из видов полиморфизма надо проверять не только тело самой функции (одно оно для всех типов или нет), но тела всех других функций, вызываемых из данной.
S>2) нет, не получается автоматически. Ты передергиваешь.
Очень даже получается. Потому что на низком уровне только ad hoc и существует. Соответственно если ты придерживаешься точки зрения, что надо проверять функции на полную глубину стека вызова, то мы абсолютно всегда найдём какой-то ad hoc.
S>Разреши, я тебе подскажу лайфках. Есть такая страничка https://wiki.haskell.org/Polymorphism и в частности https://wiki.haskell.org/Polymorphism#Ad-hoc_polymorphism.
S>Там написано, какие функции в Хаскеле параметрически (абсолютно) полиморфны, а какие — ad hoc.
S>И на тот случай, если ты не станешь читать (а vdimas не стал), я процитирую оттуда параграф (vdimas-у уже цитировал, но ты ведь не читаешь мои ответы ему).
S>
Ну вообще говоря мнение из внутреннего мирка Хаскеля при обсуждение глобальных вопросов для меня вообще не аргумент. Но в данном конкретном случае материалы по указанной тобой ссылке опять же противоречит другим твоим позициям. Потому как согласно им apply является параметрически полиморфной. А согласно твоей "кричащей" позиции — нет. )
_>>Более того, при таком подходе у тебя возникает противоречие с собственными же предыдущими утверждениями. Например ты признал что обсуждаемая ранее функция apply (в Хаскеле) — это чистый параметрический полиморфизм без всяких оговорок. Но ведь в том примере в зависимости от типа второго параметра apply (int или float) выполнялся разный код (если смотреть на весь стек вызова, а не только на само тело apply). Т.е. по твоему подходу выше та apply — это тоже ad hoc.
S>
S>Видишь? вовсе не ad hoc.
Это согласно определению из вики Хаскеля. А по твоей позиции (что надо учитывать весь стек вызова) как раз получается ad hoc.
_>>Похоже что ты не смотря на готовность привести различные цитаты других специалистов так и не сумел сформировать у себя в голове непротиворечивое определение для данного явления.
S>Вовсе нет. То что оно противоречит с твоими убеждениями (и vdimas-а тоже) — не беда вовсе. Для меня важнее что оно не противоречит с классикой, википедией и даже хаскельвики.
Очень даже противоречит. Просто ты сейчас пытаешься сделать банальнейшую манипуляцию с двойными стандартами, чтобы скрыть это. Для проверки C++ ты предлагаешь использовать одни критерии (весь оригинальные, с анализом всего стека вызова), а для проверки кода на Хаскеле (а конкретно функции apply) ты предлагаешь использовать совсем другие критерии (которые ты взял из вики Хаскеля, о наличие Eq a). Подобные дешёвые фокусы совсем не подходят для приличной дискуссии...
_>>Аналогом my_equal_to в мире Хаскеля будет такой очевидный код:
_>>
_>>Причём данные реализации (C++ и Хаскель) не только выглядят одинаково на уровне исходного кода (и даже имеют по сути одинаковые типы), но и будут крайне похожи на уровне машинного.
S>тадам....
S>
А я разве где-то писал, что согласен с подобными критериями? ) Данная функция выглядит одинаково для всех типов и в исходных и в машинных кодах. Покажи что конкретно по твоему не укладывается в ней в цитируемое тобой же определение параметрического полиморфизма (например из TAPL).
_>>В смысле не согласен? Машинный код одинаков для всех типов с точностью до бита (эту функции в отличие от шаблонной можно скомпилировать в отдельный бинарный модуль). Это просто факт, с которым ничего нельзя поделать.
S>Машинный код сравнения двух значений не может быть независимым от типов этих значений. Эти значения просто нельзя начинать сравнивать, не зная их тип. Значит, если код твоей функции от типов не зависит, то он должен принять нечто, что позволит косвенно перейти к специализации сравнения. Классы типов хаскеля — это и есть эта косвенность.
S>А раз есть косвенность, значит есть и зависимость от специализации. А значит — ad hoc.
Да, естественно my_equal_to неявно параметризуется (знакомое слово, не так ли?
) указателем на оператор сравнения для нужного типа. И приблизительно так же работают внутренние механизмы, позволяющие функционировать Хаскелю. А в чём собственно проблема то? Или ты снова пытаешься подправить определения, так что бы они укладывались под твоё противоречивое мировоззрение? ) Изначально у нас было очевидное определение "единый код для всех типов", а небольшой спор был лишь на тему стоит ли тут учитывать только исходный код (на мой вкус только это и важно) или надо учитывать ещё и генерируемый для функции машинный код. Ну вот тут мы имеем пример с одинаковым для всех типов и исходным и машинным кодом, и теперь ты пытаешься добавить ещё какие-нибудь оговорки. )))_>>Если же ты снова намекаешь на то, что данная реализация функции определена не для всех возможных типов (а только для имеющих оператор равенства), то это ничего не меняет. Потому что только для таких типов эта функция и будет использоваться — других вариантов (которые теоретически могли бы создать тот самый ad hoc через перегрузку) не будет в принципе.
S>Но для тех типов будет выполнен разный код сравнения, специальный для каждого типа? Я не про верхнюю функцию я про именно самый низкий уровень сравнения. Если разный — значит функция верхнего уровня, использующая эти разные коды — ad hoc. И я тут не намекаю уже. КРИЧУ!
Ага, ага, только смотрим на этот код на Хаскеле:
apply f a = f a
f a = a + 1
apply f 1 -- выполняется код сложения для Int
apply f 1.0 -- выполняется код сложения для Floatи видим, что следуя твое логике apply — это очевидный ad hoc. Ой. Вот уж действительно повод для криков. )
_>>Естественно разные, но это всё будет происходить не в теле функции my_equal_to, так что не имеет к ней отношения. Если же ты будешь настаивать в своём определение на учёт внутреннего устройства ещё и всех других функций (вызываемых из обсуждаемой), то тогда у тебя автоматически получится, что вокруг абсолютно всё ad hoc полиморфизм, а параметрического не существует вовсе (потому что на самом низком уровне всё ad hoc).
S>1) я не знаю, почему ты определение называешь моим, оно везде. А вот твое я нигде не нашел более (а источник ты не указал).
Ну ка покажи где это было указано, что для проверки функции на принадлежность к одному из видов полиморфизма надо проверять не только тело самой функции (одно оно для всех типов или нет), но тела всех других функций, вызываемых из данной.
S>2) нет, не получается автоматически. Ты передергиваешь.
Очень даже получается. Потому что на низком уровне только ad hoc и существует. Соответственно если ты придерживаешься точки зрения, что надо проверять функции на полную глубину стека вызова, то мы абсолютно всегда найдём какой-то ad hoc.
S>Разреши, я тебе подскажу лайфках. Есть такая страничка https://wiki.haskell.org/Polymorphism и в частности https://wiki.haskell.org/Polymorphism#Ad-hoc_polymorphism.
S>Там написано, какие функции в Хаскеле параметрически (абсолютно) полиморфны, а какие — ad hoc.
S>И на тот случай, если ты не станешь читать (а vdimas не стал), я процитирую оттуда параграф (vdimas-у уже цитировал, но ты ведь не читаешь мои ответы ему).
S>
S>Я не знаю, будешь ли ты спорить с хаскельвики, но эта цитата по-крайней мере является свидетельством того, что не я один придерживаюсь определения, авторство которого ты приписываешь мне. Если, конечно, я не подправил хаскельвики.S>You can recognise the presence of ad-hoc polymorphism by looking for constrained type variables: that is, variables that appear to the left of =>, like in elem :: (Eq a) => a -> [a] -> Bool. Note that lookup :: (Eq a) => a -> [(a,b)] -> Maybe b exhibits both parametric (in b) and ad-hoc (in a) polymorphism.
Ну вообще говоря мнение из внутреннего мирка Хаскеля при обсуждение глобальных вопросов для меня вообще не аргумент. Но в данном конкретном случае материалы по указанной тобой ссылке опять же противоречит другим твоим позициям. Потому как согласно им apply является параметрически полиморфной. А согласно твоей "кричащей" позиции — нет. )
_>>Более того, при таком подходе у тебя возникает противоречие с собственными же предыдущими утверждениями. Например ты признал что обсуждаемая ранее функция apply (в Хаскеле) — это чистый параметрический полиморфизм без всяких оговорок. Но ведь в том примере в зависимости от типа второго параметра apply (int или float) выполнялся разный код (если смотреть на весь стек вызова, а не только на само тело apply). Т.е. по твоему подходу выше та apply — это тоже ad hoc.
S>
S>Prelude> apply f a = f a
S>Prelude> :t apply
S>apply :: (t -> t1) -> t -> t1
S>S>Видишь? вовсе не ad hoc.
Это согласно определению из вики Хаскеля. А по твоей позиции (что надо учитывать весь стек вызова) как раз получается ad hoc.
_>>Похоже что ты не смотря на готовность привести различные цитаты других специалистов так и не сумел сформировать у себя в голове непротиворечивое определение для данного явления.
S>Вовсе нет. То что оно противоречит с твоими убеждениями (и vdimas-а тоже) — не беда вовсе. Для меня важнее что оно не противоречит с классикой, википедией и даже хаскельвики.
Очень даже противоречит. Просто ты сейчас пытаешься сделать банальнейшую манипуляцию с двойными стандартами, чтобы скрыть это. Для проверки C++ ты предлагаешь использовать одни критерии (весь оригинальные, с анализом всего стека вызова), а для проверки кода на Хаскеле (а конкретно функции apply) ты предлагаешь использовать совсем другие критерии (которые ты взял из вики Хаскеля, о наличие Eq a). Подобные дешёвые фокусы совсем не подходят для приличной дискуссии...
_>>Аналогом my_equal_to в мире Хаскеля будет такой очевидный код:
_>>
_>>my_equal_to a b = a==b
_>>_>>Причём данные реализации (C++ и Хаскель) не только выглядят одинаково на уровне исходного кода (и даже имеют по сути одинаковые типы), но и будут крайне похожи на уровне машинного.
S>тадам....
S>
S>ad hoc.S>Prelude> my_equal_to a b = a==b
S>Prelude> :t my_equal_to
S>my_equal_to :: Eq a => a -> a -> Bool
А я разве где-то писал, что согласен с подобными критериями? ) Данная функция выглядит одинаково для всех типов и в исходных и в машинных кодах. Покажи что конкретно по твоему не укладывается в ней в цитируемое тобой же определение параметрического полиморфизма (например из TAPL).