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

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

S>>Странно что ты не сделал вывод о том что я предлагаю пойти к гадалке. Все определения, что я приводил, ты видел, причем, неоднократно. И в некоторых (Strachey 67, TAPL) отсылка к исполняемому коду действительно есть. Но это вытекает именно из них, а не из того, что я сказал что исходников недостаточно.

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

_>1. Считаешь ли ты, что при анализе вида полиморфизма некой функции, достаточно смотреть только на её исходный код и всё?
Нет.
_>2. Если на первый вопрос ответ отрицательный, то сформулируй чётко и подробно (опиши алгоритм) что по твоему надо проанализировать ещё.
Ты забыл сказать "пожалуйста". Но, я, пожалуй, отвечу таки. Из определения TAPL следует необходимость анализа поведения, будет ли оно разным для разных типов. По Strachey 67 становится ясно что нужно анализировать, будет ли выполняться различный код для каждого типа.

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

_>И? ) Тебе что-то не нравится? )
То, что различный код для equal_to выполняется, но ты уперся "в тело".

S>>apply — ФВП. Чем ты ее параметризуешь, то и получишь. То что ты возьмешь (из другой ветки) чистую функцию map и подставишь в нее грязную лямбду и получишь при выполнении грязь — у тебя вроде не создает аналогичный батхерд.

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

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

S>>Я говорю что твоя классификация фундаментального понятия оказалась зависимой от конкретной реализации конкретного языка. И при изменении генерируемого кода тебе придется как флюгеру крутиться.

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

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

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

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

S>>О, т.е. твои критерии не просто от частной реализации конкретного языка зависят, а еще и от того, в отдельный ли модуль или не в отдельный? Ка же тебе сложно крутиться-то.

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

_>Я так понимаю, что тебе показалось, что ты тут обнаружил какое-то противоречие в моих словах? ) Но я что-то в упор его не вижу. Расшифруй в деталях, что конкретно тебе тут не нравится.
Пожалуйста:
Один раз ты сравнил поведения двух различных функций, у которых различная реализация на уровне машинных кодов. При этом сказал что поведение будет "как у", т.е. одинаковое. Я полагаю, ты интуитивно использовал procedural abstraction.

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

В этом же сообщении ты в отношении другой (других функций) my_equal_to заявил что их поведение абсолютно одинаковое, но при этом перешел от поведения функций к поведению исполнителя при очевидно разном поведении функций на уровне procedural abstraction для разных типов.

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

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

То есть у тебя слово "поведение" вызывает некий диссонанс, что может объяснять проблемы понимания определений, использующих слово "поведение".
И если в определениях использовать твой первый вариант (процедурной абтракции), то как раз и выйдет, что функция my_equal_to ведет себя по разному для разных типов, а значит вписывается в ad-hoc.
Но ты почему-то уперся и используешь второе понятие — поведение исполнителя (через вызов оператора).

Хотя, заметь! Сам ты используешь оба смысла слова "поведение", причем, даже в одном посте, и наверняка с разницей не более пары минут.