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

S>>>Учитывая выделенное "Но при том ее ad hoc природу не отнять" мне как-то сложно согласиться с "консесусом".
_>>А мне кажется что в данном http://rsdn.org/forum/flame.comp/6678712.1

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

сообщение как раз наблюдается полный консенсус. )))
S>А мне не кажется

Ну тогда тебе видимо стоит немного походить на курсы русского языка. )

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

Ууу какой ты занудный. Ведь всем же (в том числе и тебе) очевидно, что ты пытаешься придумывать отмазки на пустом месте, чтобы замять свои же противоречия. Ну ОК, если тебе так хочется, то давай поиграем в формализм и крючкотворство. И так, по пунктам:

1. Считаешь ли ты, что при анализе вида полиморфизма некой функции, достаточно смотреть только на её исходный код и всё?
2. Если на первый вопрос ответ отрицательный, то сформулируй чётко и подробно (опиши алгоритм) что по твоему надо проанализировать ещё.

_>>Ну так укажи где конкретно в данных источниках указано про необходимость анализа машинного кода (да ещё и всего стека вызовов).
S>Что, опять? Ты их уже поскипал разок.
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

В данные цитатах нет ни одного слова про подобное. Или у тебя своё особое понимание и английского языка?

_>>Во всех определениях используется нормальное понятие "код" или "кусок кода" и т.п. Т.е. речь о том, что мы берём конкретный код (машинный или исходный — не суть, хотя результаты могут быть разные) и говорим относится он к параметрическому полиморфизму или к ad hoc. Тело функции отлично укладывается в подобное определение.
S>Я же говорю. Укладывается, но не исчерпывает. Т.е. когда ты видишь фразу "while an ad-hoc polymorphic function may execute different code for each type of argument", ты просто говоришь, что в теле этой конкретно функции нет исходного кода для другого типа. Наверное, очень доволен собой.

И? ) Тебе что-то не нравится? )

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

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

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

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

Вообще то я об этом писал ещё в самом начале, а до тебя похоже только сейчас дошло. И то не совсем верно — речь идёт только о полиморфизме машинного кода. Я же, как ты наверное помнишь, разделяю эти два понятия. Так вот например функция std::equal_to является очевидно параметрически полиморфной на уровне исходного кода. И никакие реализации компилятора этого не поменяют. Но они могут поменять вид полиморфизма на уровне машинного кода. Нынешняя реализация шаблонов C++ очевидно представляет собой ad hoc на уровне машинного кода. Однако если мы заменим эту реализацию на механизмы из Хаскеля (помнишь я писал о таком мысленном эксперименте ещё в самом начале дискуссии?), то весь код по прежнему будет работать. Но при этом на уровне машинного кода будет наблюдаться уже медленный параметрический полиморфизм.

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

_>>Во-первых не надо чего-то допускать и предполагать, если можно точно знать (все обсуждаемые вещи точно описаны в документации, а не отданы на некий произвол компилятора (по твоему у него там своя воля есть что ли? )).
S>Есть, конечно. И не по-моему, а по процедурной абстракции.

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

_>>А во-вторых я специально делал во всех примерах оговорку (или ты думаешь этот пункт просто так был в описаниях примеров?), что изначальная функция компилируется в отдельный бинарный модуль — это на корню исключает все возможные оптимизации и т.п., способные поменять расклад наших рассуждений.
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>Выше ты использовал понятие поведения функции в фразе "В этом случае на уровне машинных кодов появится отдельная функция с поведение как у apply f, но при этом она будет всего лишь обёрткой над apply."
S>Это как у тебя получилось что поведение обертки и функции одинаковое, притом что тут ты под поведением подразумеваешь лишь "вызов оператора"? Сам себя поймал, однако.

Я так понимаю, что тебе показалось, что ты тут обнаружил какое-то противоречие в моих словах? ) Но я что-то в упор его не вижу. Расшифруй в деталях, что конкретно тебе тут не нравится.