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

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

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

Да, и кстати насчёт "вышки". Я что-то не помню ни одного технического факультета (во всяком случае там, где учился я, в МГУ) в котором был бы такой предмет. У нас помнится был мат.анализ, несколько видов алгебр, несколько видов геометрий, дифуры, интуры с вариационным исчислением, тфкп, тер.вер со статистикой, функциональный анализ, теория групп и т.п. А предмет с названием "высшая математика" — это разве что у гуманитариев каких-нибудь может быть, которым требуется только обзорный курс. И то, что ты знаешь именно его наводит на определённые мысли — может ты как раз из тех самых политологов?. ))) Тем более что и стиль ведения дискуссии у тебя явно подходящий: для тебя важнее не суть, а формальность. )

_>>Ну т.е. ты так и не можешь представить своё определение понятия "поведение функции"? Хотя при этом говоришь что все его понимают одинаковым образом (так каким же тогда?)...
S>А для чего мне представлять именно свое определение? Свое понимание (и не только мое) этого вопроса — я уже излагал. Указывал, где посмотреть на специфику для C++. Мало? Извини, определения поведения функции в аппаратных стеках у меня нема.

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

_>>Глупости какие. Если убрать библиотечный сахар (реализуемый через МП) в 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 параметрически полиморфная.
S>Видишь, реализации! А в терминах поведения они существенно отличаются. apply ведет себя неотличимо от любой (здесь я использовал квантор всеобщности, если ты когда-нибудь с ними таки ознакомишься) функцции f. А my_equal_to ведет себя неотличимо от eq для каждого типа, для которого определен eq. А значит, специальнымм образом на ограниченном наборе. Но ты гляди в аппаратный стек, что бы не ошибиться. Оттуда, наверное, вообще все функции полиморфными кажутся

1. В одних твоих сообщения было указано, что apply — это параметрически полиморфная функция, без всяких оговорок. А в других (вот как сейчас например) ты пишешь, что поведение apply полностью определяется функцией f (которая естественно может быть и ad hoc). Так как с тобой вести нормальную дискуссию, если у тебя позиция скачет от одного сообщения к другому? )
2. Определение eq лежит вне определения функции my_equal_to. Соответственно если ты привлекаешь его устройство для определения свойств my_equal_to, то это значит что ты постулируешь тот факт, что для определения вида полиморфизма некого кода абсолютно недостаточно ни знания исходного кода (и даже вместе с моделью вычисления), ни знания машинного кода. А требуется знание внутреннего устройства некого постороннего кода. Правильно?
3. Рассмотрим такой простейший код:

auto my_equal_to2=[](bool x, eq a, eq b) {return x||a==b;};
auto f=[](bool x, eq a, eq b) {return my_equal_to2(true, a, b);};
auto g=[](bool x, eq a, eq b) {return my_equal_to2(false, a, b);};

Я правильно понимаю, что с твоих "поведенческих" понятий функция f получается параметрически полиморфной, а функция g ad hoc полиморфной? И соответственно тогда вопрос, какой с твоей точки зрения является функция my_equal_to2? )