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

_>>Перечитай ещё раз весь текст с начала и разберись уже наконец, кто реально тут не понимает.
S>Нет смысла. Кванторы — твоя слабая сторона.

Мда, так и не понял. Сочувствую. )

_>>Ну и отдельно замечу, что попытки подобного стиля общения на инженерном форуме от человека, который несколькими сообщениями ранее не сомневался в реализации каррирования в машинных кодах (от одной мысли о подобном любой студент изучивший базовые принципы устройства ЦПУ смеялся бы очень долго), выглядят довольно жалко и убого.
S>Хы, пропустил я как-то момент, когда студенты начали изучать принципы устройства ЦПУ c реализации каррирования в GHC.

Ты похоже уже забыл, что я тебе уже писал. Для того, чтобы посмеяться над идеей каррирования в машинных кодах не надо ничего знать про какие-то реализации Хаскеля и т.п. Это смешно само по себе, если знать устройство современных процессоров (попробуй просто представить себе что потребуется сгенерировать компилятору и как будет выглядеть вызов всего этого скажем в случае функции 5-и переменных). И то, что ты по прежнему этого не понимаешь, прямо поражает. Ты вообще в курсе таких вещей как аппаратный стек, пролог и эпилог функции и т.п. базовые вещи, знакомые каждому студенту? )

S>Да и похоже что сам Стрэчи, введя классификацию в 1967м году выглядел бы жалко и убого. Он, бедолага, и Хаскеля-то не видел. Как он вообще мог, не зная частной реализации каррирования в машинных кодах, вводить такие классификации!!!

The name "currying", coined by Christopher Strachey in 1967, is a reference to logician Haskell Curry.

_>>Пролистал до конца сообщения но так и не нашёл определения для "поведения функции". Ни научного, ни даже твоего личного. Где оно?
S>Тебе надо было листать не мое сообщение, а спецификацию C++. Я вроде бы недвусмысленно указал на это. Да ладно уж.

Ну т.е. ты так и не можешь представить своё определение понятия "поведение функции"? Хотя при этом говоришь что все его понимают одинаковым образом (так каким же тогда?)...

_>>В прошлом ты пытался выкрутиться из этого противоречия в своём мировоззрение с помощью утверждения, что "apply f" — это уже совсем другая функция с другими свойствами. Когда же ты открыл для себя, что в реальности используется всё та же apply, то начал придумывать новые отмазки, что мол для ФВП надо делать исключения и определять их по другому. Так что конкретно ты имеешь в виду под "своим мнением"? В этом потоке судорожных попыток как-то замять противоречивость никакой чёткой и однозначной позиции я так и не увидел.
S>Мне жаль.

Ну т.е. и насчёт противоречия с apply тебе сказать нечего? ) Что-то ты совсем сдулся как оппонент. )

_>>Ну вот, сам же видишь противоречия в своей позиции. В реальности между работой apply и my_equal_to нет никакой разницы. Причём это вне зависимости от того как на них смотреть, с твоих позиций или с моих — эти функции одинаковы по своему устройству. Только вот с моими взглядами (где всё обсуждаемое параметрически полиморфно) этот факт отлично сочетается, а с твоими (в которых одна из этих функций почему-то ad hoc, а другая нет) наблюдается противоречие.
S>Я уже перчислял, чему противоречат твои взгляды. Возможно, тебе стоило бы озадачитьься этим, а не искать противоречие в моих.

И тут тебе сказать нечего. В общем всё понятно.

_>>Ничего общего с твоим бредом тут нет. Операторов равенства для разных типов много — это и есть ad hoc. А оператор равенства для eq ровно один.
S>функция
S>myEq a b = a == b
S>тоже одна. И она ad-hoc.

Глупости какие. Если убрать библиотечный сахар (реализуемый через МП) в C++ варианте и синтаксический сахар (посмотреть на внутреннюю реализацию классов типов) Хаскеля, то легко увидеть, что в обоих вариантах эти функции в реальности выглядят как-то так:

bool my_equal_to(void* a, void* b, bool (*f)(void*, void*))
{
    return f(a, b);
}

а значение f автоматически подставляется компилятором (по определению работы Хаскеля/по МП коду в конструкторе eq в варианте C++) в точках вызова my_equal_to в соответствие с передаваемыми там типами. Никакого принципиального отличия от обсуждаемой тут apply эти реализации не имеют. Но при этом они у тебя ad hoc полиморфные, а apply параметрически полиморфная.