Re[16]: IEquatable<T> - Компьютерные священные войны

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

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

S>>Дада, я вот тоже для тебя западню заготовил, но вот беда (и смешно и обидно вышло... ) переоценил уровень твоего бэкграунда. И ты пролетел мимо этой засады, даже не поморщился. Ну что ж, попробую тебя оттормозить, оттащить назад и все-таки посадить в эту лужу.

_>Давно не видел такого длинного и при этом бессмысленного (одна вода) текста на данном форуме. Ну да ладно, попытаюсь вычленить из него хоть какие-то тезисы.
Жаль, что не вычленил про поведение. Ну да ладно.

_>Для начала напомню, что все последние сообщения у нас идёт дискуссия исключительно о полиморфизме на уровне машинных кодов. Потому что на уровне исходных кодов мы уже давно всё обсудили и пришли к консенсусу, что все версии equal_to (включая шаблонную std::equal_to, с которой всё началось) реализуют параметрический полиморфизм.
То ли короткая память, то ли демагогия. Я допускал такое с некоторыми оговорками. Надеюсь, найдешь.

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

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

Не хочешь — не надо, я ж тебя не заставляю. Оставим просто как есть. Пирс, википедия, хаскельвики за ad hoc equal_to. Твое мнение никто не разделяет.

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

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

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

_>>>Где-то в моём примере объявлена или используется функция вида "g = apply f"? ) Не надо подобных дешёвых фокусов.
S>>В том, что касается дешевых фокусов, используя понятие процедурной абстракции, можно верить тому, что поведение функции apply f не отличимо от поведения функции f, и оно же неотличимо от "g = apply f". Если бы это было не так, то функцию apply с аргументом f нельзя было бы использовать вместо функции f. Но ты ее как раз используешь исходя из сохранения поведения. Значит, должен быть удовлетворен любой подстановкой с сохранением его. Если нет — выполняй f сам.

_>Объясняю ещё раз на доступном языке. Мы здесь изучаем поведение машинных кодов. Если ты нигде не использовал явно функцию вида "apply f" (а в моём примере такого не было), то в машинных кодах её не будет существовать в принципе. Более того, даже если ты где-то в проекте и используешь её (так что в итоге подобный код будет существовать в итоговом исполняемом файле), то в процессе выполнения моих примеров она всё равно вызываться не будет (всё равно будет прямой вызов нормальной apply с двумя параметрами). Теперь понятно? )
Что это меняет?

_>>>А, ну да) Остроумно. ))) И много таких функций встречается в твоих приложениях? )
S>>О, рад что ты оценил. Да, параметрически полиморфных функций в моих приложениях встречается много.

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

_>>>Ты вот что, серьёзно верил, что каррирование реально существует на уровне машинных кодов? Да если бы кто-то и попытался сделать подобное, то оно работало бы не просто медленно (как нынешний Хаскель), а вообще почти не шевелилось бы (наверное хуже чем какой-нибудь bash).
S>>Ну причем тут "медленно"?

_>Притом что:
_>1. Именно по это причине Хаскель работает не так, как тебе воображалось
_>2. Именно по этой причине любой вменяемый (знающий хотя бы основы функционирования современных ЦПУ) программист знал бы правильный ответ без обращения к документации ghc. Так что твои заблуждения в данной области наводят на определённые мысли...
Ну работает не так, работает чуть быстрее, чем мне воображалось. От этого поменялась классификация?

_>>>https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/HaskellExecution/FunctionCalls — на вот, просвещайся как обстоят дела в реальности, чтобы не писать больше подобных глупостей.
S>>Вот видишь, согласно понятию процедурной абстракции хаскель может генерить несколько различных тел для одной функции и вызывать их в зависимости от обстоятельств вызова. Сохраняя, при этом поведение, соответствующее execution model. Если завтра технические детали реализации поменяются с "просто медленно" на "вообще почти не шевелилось бы", но сохранится execution model, то на поведение функций apply, f, apply f это не повлияет. Следовательно, сохранится их параметрическая классификация. Будь уверен в этом.

_>Эм, ты даже такой очевидный текст не можешь нормально воспринять? ) Генерируется ровно один машинный код данной функции. Самый обычный (не с одним аргументом), который ты можешь положить в отдельный бинарный файл. И все вызовы вида "apply f 1" и т.п. (с полным набором аргументов) будут осуществлять прямой вызов этой функции. 80% кода на Хаскеле попадает именно в эту категорию (по этому и более менее шевелится). Плюс к этому, если где-то в приложение встретится отдельная конструкция вида "apply f", то будет сгенерирована (в уже другом бинарном модуле) ещё одна функция, реализующая частичное применение функции apply (естественно через вызов изначальной).
О, то есть еще одна все-таки бывает. Спасибо, что подтвердил то что я "не смог нормально воспринять".

Очень мило что ты замел под ковер свой косяк с трактоваками поведения функции. Считаю это еще одним признаком моей правоты.

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

_>>Для начала напомню, что все последние сообщения у нас идёт дискуссия исключительно о полиморфизме на уровне машинных кодов. Потому что на уровне исходных кодов мы уже давно всё обсудили и пришли к консенсусу, что все версии equal_to (включая шаблонную std::equal_to, с которой всё началось) реализуют параметрический полиморфизм.
S>То ли короткая память, то ли демагогия. Я допускал такое с некоторыми оговорками. Надеюсь, найдешь.

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

_>>Сейчас же мы уже обсуждаем исключительно генерируемый этими функциями машинный код, т.е. совсем низкий уровень (ассемблерные инструкции и т.п.). И если ты не готов к дискуссии на таком уровне (например оказалось, что ты даже смутно не представляешь какой код генерируется по тем примерам на Хаскеле, что мы обсуждали), то возможно и не стоило её начинать?
S>Ненене, мы не обсуждаем исключительно генерируемый код. Мы обсуждаем классификацию, согласно которой equal_to — ad hoc. В дискуссии об исключительно машинном коде я тебе не оппонент. Т.к. я не видал классификаций, которые бы говорили об исключительно машинном коде. Если это ты их выдумал, то приведи их и скажи, что это ты выдумал. Если подглядел где — сошлись на источник.

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

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

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

S>Не хочешь — не надо, я ж тебя не заставляю. Оставим просто как есть. Пирс, википедия, хаскельвики за ad hoc equal_to. Твое мнение никто не разделяет.

Ну а это уже откровенное враньё.

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

А причём тут я? У меня то совсем другая точка зрения (в которой надо смотреть только на тело функции и в которой все обсуждаемые параметрически полиморфны), в которой никаких противоречий нет. А вот тебя, с твоими противоречивыми взглядами это действительно должно смущать.

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

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

Ну вот видишь, ты же сам тут указал, что при таком подходе вид полиморфизма my_equal_to ничем не отличается от apply — зависит от внешних факторов (устройства функции f или оператора равенства для типа eq).

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

Пару сообщений назад я попросил тебя зафиксировать свою позицию по данному вопросу, что ты и сделал далее. Дать ссылку на твою цитату или сам найдёшь? )

_>>Притом что:
_>>1. Именно по это причине Хаскель работает не так, как тебе воображалось
_>>2. Именно по этой причине любой вменяемый (знающий хотя бы основы функционирования современных ЦПУ) программист знал бы правильный ответ без обращения к документации ghc. Так что твои заблуждения в данной области наводят на определённые мысли...
S>Ну работает не так, работает чуть быстрее, чем мне воображалось. От этого поменялась классификация?

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

_>>Эм, ты даже такой очевидный текст не можешь нормально воспринять? ) Генерируется ровно один машинный код данной функции. Самый обычный (не с одним аргументом), который ты можешь положить в отдельный бинарный файл. И все вызовы вида "apply f 1" и т.п. (с полным набором аргументов) будут осуществлять прямой вызов этой функции. 80% кода на Хаскеле попадает именно в эту категорию (по этому и более менее шевелится). Плюс к этому, если где-то в приложение встретится отдельная конструкция вида "apply f", то будет сгенерирована (в уже другом бинарном модуле) ещё одна функция, реализующая частичное применение функции apply (естественно через вызов изначальной).
S>О, то есть еще одна все-таки бывает. Спасибо, что подтвердил то что я "не смог нормально воспринять".

Мда, похоже примеры с устройством Хаскеля реально слишком сложные. Давай проясним глупость твоих фраз (про "несколько тел для одной функции" и т.п.) на простейшем C++ примере, который аналогичен (если опять же собирать в отдельных бинарных модулях, а то иначе инлайнинг вообще убьёт все эти функции) внутреннему устройству Хаскеля:

auto f=[](int x, int y) {return x+y;};
auto g=[](int y) {return f(1, y);};
f(1, 2);

Так вот, по этому коду можешь ли ты сказать что:
1. вторая строчка хоть как-то влияет на третью
2. что компилятор генерирует несколько тел для функции f.

И если не можешь, то почему говоришь аналогичный бред про случай с Хаскелем? )

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

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

S>>То ли короткая память, то ли демагогия. Я допускал такое с некоторыми оговорками. Надеюсь, найдешь.

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

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

Т.е. я могу согласиться с тем, что equal_to параметрически полиморфна на множестве типов с определенным оператором сравнения, объединенном с множеством типов, для которых существует явная специализация equal_to. Но при этом ее ad hoc природу не спрятать.

А перед ней цитата из вики

Класс типов осуществляет диспетчеризацию статически, сводя параметрический>>> и ad hoc>>> полиморфизм в единую модель[12]. С точки зрения параметрического полиморфизма, класс типов имеет параметр (переменную типа), пробегающий множество типов. С точки зрения ad hoc полиморфизма, это множество не только дискретно, но и задано явным образом до уровня реализации. Проще говоря, сигнатура square :: Num a => a -> a означает, что функция параметрически полиморфна, но спектр типов её параметра ограничен лишь теми типами, что принадлежат к классу типов Num. Благодаря этому, функция типизируется единственным образом, несмотря на обращение к перегруженной функции из её тела.

Учитывая выделенное "Но при том ее ad hoc природу не отнять" мне как-то сложно согласиться с "консесусом".

_>>>Сейчас же мы уже обсуждаем исключительно генерируемый этими функциями машинный код, т.е. совсем низкий уровень (ассемблерные инструкции и т.п.). И если ты не готов к дискуссии на таком уровне (например оказалось, что ты даже смутно не представляешь какой код генерируется по тем примерам на Хаскеле, что мы обсуждали), то возможно и не стоило её начинать?
S>>Ненене, мы не обсуждаем исключительно генерируемый код. Мы обсуждаем классификацию, согласно которой equal_to — ad hoc. В дискуссии об исключительно машинном коде я тебе не оппонент. Т.к. я не видал классификаций, которые бы говорили об исключительно машинном коде. Если это ты их выдумал, то приведи их и скажи, что это ты выдумал. Если подглядел где — сошлись на источник.

_>Что-то у тебя какая-то короткая память. Это как раз я неоднократно заявлял, что лично мне более чем достаточно факта параметрического полиморфизма на уровне исходного кода, а что там творится в машинных кодах вообще не принципиально. А ты наоборот начал говорить о важности анализа машинных кодов, чем мы и занялись. Правда в итоге оказалось, что в данной области ты очень слабо разбираешься, так что это твоё желание углубиться на уровень машинных кодов действительно очень странно. Но если ты посмотришь на историю сообщений в данной теме, то легко увидишь, что это было именно твоё желание.
Да, ты такое заявлял. А я потом спросил, видел ли ты определение, которое довольствовалось бы лишь исходником. А к анализу машинных кодов все время ты склонял.

S>И как возможность оптимизации влияет на классификацию?

Я поясняю разницу в реализации Хаскеля и C++. На уровне исходного кода её нет. А на уровне генерируемого машинного разница заметная (обмен возможности модульности на производительность).

или так

S>Так что, equal_to — ad hoc?

Которая std::equal_to? На уровне исходных кодов — нет. На уровне машинных — пожалуй. Точнее на уровне машинных кодов её не будет вовсе, а будет только вставленный на место её вызова код оператора равенства (который ad hoc). Я вроде это всё сказал ещё в самом начале дискуссии.

И соответственно будет интересно услышать от тебя какая разница у этого кода с примером на Хаскеле. И на уровне исходных кодов и на уровне машинных.

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

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

S>>Не хочешь — не надо, я ж тебя не заставляю. Оставим просто как есть. Пирс, википедия, хаскельвики за ad hoc equal_to. Твое мнение никто не разделяет.

_>Ну а это уже откровенное враньё.
Так опровергни

S>>Что ей передали первымм аргументом, то и будет в стеке. Передали ad-hoc функцию, получился в стеке ad-hoc, Передали параметрическую — значит в стеке нет ad-hoc. Не смущает неоднозначность такого подхода?

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

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

S>>Потому что оператор равенства разный для разных типов. У него разные поведения, разные математические свойства в зависимости от типа. Если ты подсунешь в my_equal_to единый способ сравнения для всех типов (не использующий штатные перегрузки оператора ==), то она станет параметрической, но какое отношение она будет иметь к сравнению через оператор равенства — вопрос отдельной дискуссии.

_>Ну вот видишь, ты же сам тут указал, что при таком подходе вид полиморфизма my_equal_to ничем не отличается от apply — зависит от внешних факторов (устройства функции f или оператора равенства для типа eq).
Еще раз прочитай, пожалуйста, что именно я тебе ответил. Внимательно.

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

_>Пару сообщений назад я попросил тебя зафиксировать свою позицию по данному вопросу, что ты и сделал далее. Дать ссылку на твою цитату или сам найдёшь? )
Позицию — было. Причем, я сказал, что вообще речь о поведении. Свое ТАКОЕ определение я не давал, тем более, что то что ты мне предлагал выбрать в качестве позиции не может дать однозначный ответ по apply.

S>>Ну работает не так, работает чуть быстрее, чем мне воображалось. От этого поменялась классификация?

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

_>>>Эм, ты даже такой очевидный текст не можешь нормально воспринять? ) Генерируется ровно один машинный код данной функции. Самый обычный (не с одним аргументом), который ты можешь положить в отдельный бинарный файл. И все вызовы вида "apply f 1" и т.п. (с полным набором аргументов) будут осуществлять прямой вызов этой функции. 80% кода на Хаскеле попадает именно в эту категорию (по этому и более менее шевелится). Плюс к этому, если где-то в приложение встретится отдельная конструкция вида "apply f", то будет сгенерирована (в уже другом бинарном модуле) ещё одна функция, реализующая частичное применение функции apply (естественно через вызов изначальной).
S>>О, то есть еще одна все-таки бывает. Спасибо, что подтвердил то что я "не смог нормально воспринять".

_>Мда, похоже примеры с устройством Хаскеля реально слишком сложные. Давай проясним глупость твоих фраз (про "несколько тел для одной функции" и т.п.) на простейшем C++ примере, который аналогичен (если опять же собирать в отдельных бинарных модулях, а то иначе инлайнинг вообще убьёт все эти функции) внутреннему устройству Хаскеля:
Ух ты, инлайнинг вообще убьёт все эти функции, какой кошмар! Где адреса, где стек на всю глубину? Почему компилятор позволяет себе то убивать функции, то вставлять тело?
_>

_>auto f=[](int x, int y) {return x+y;};
_>auto g=[](int y) {return f(1, y);};
_>f(1, 2);
_>

_>Так вот, по этому коду можешь ли ты сказать что:
_>1. вторая строчка хоть как-то влияет на третью
Вряд ли.
_>2. что компилятор генерирует несколько тел для функции f.
Ты же не показал 5ую и 10ю, в которых f(a, 2) * f(a, b) и передача f в какуюнибудь ФВП.

_>И если не можешь, то почему говоришь аналогичный бред про случай с Хаскелем? )
Еще раз, согласно понятию процедурной абстракции можно подменять одно тело другим с сохранением поведения. И даже удалять тело, заменять его значением, или вообще выкидывать, если это не скажется на поведении. То что я написал что хаскель может это делать, отсюда совершенно не вытекает будто я утверждаю что он именно так делает.
Вот ты тут пугаешься что C++ выкинет твои функции. А ты уверен что хаскель не выкинет функцию apply, подменив ее вызовом f? Делает ли он вызов $ при каждом упоминании? Может ли это измениться с сохранением execution model? Я это допускаю. И это не влияет на классификацию полиморфизма.

Так что с твоей оговоркой про поведение функций?

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

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

Точно короткая память — я взял это не оттуда. )))

S>Учитывая выделенное "Но при том ее ad hoc природу не отнять" мне как-то сложно согласиться с "консесусом".

А мне кажется что в данном http://rsdn.org/forum/flame.comp/6678712.1 сообщение как раз наблюдается полный консенсус. )))

_>>Что-то у тебя какая-то короткая память. Это как раз я неоднократно заявлял, что лично мне более чем достаточно факта параметрического полиморфизма на уровне исходного кода, а что там творится в машинных кодах вообще не принципиально. А ты наоборот начал говорить о важности анализа машинных кодов, чем мы и занялись. Правда в итоге оказалось, что в данной области ты очень слабо разбираешься, так что это твоё желание углубиться на уровень машинных кодов действительно очень странно. Но если ты посмотришь на историю сообщений в данной теме, то легко увидишь, что это было именно твоё желание.
S>Да, ты такое заявлял. А я потом спросил, видел ли ты определение, которое довольствовалось бы лишь исходником. А к анализу машинных кодов все время ты склонял.

Это феерично.

Т.е. по твоему анализа исходников недостаточно, но это не означает необходимость анализа машинных кодов? ) А что же это тогда означает? ))) Ты там не запутался ещё в своих тезисах? )))

S>>>Не хочешь — не надо, я ж тебя не заставляю. Оставим просто как есть. Пирс, википедия, хаскельвики за ad hoc equal_to. Твое мнение никто не разделяет.
_>>Ну а это уже откровенное враньё.
S>Так опровергни

Ну так укажи где конкретно в данных источниках указано про необходимость анализа машинного кода (да ещё и всего стека вызовов).

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

Во всех определениях используется нормальное понятие "код" или "кусок кода" и т.п. Т.е. речь о том, что мы берём конкретный код (машинный или исходный — не суть, хотя результаты могут быть разные) и говорим относится он к параметрическому полиморфизму или к ad hoc. Тело функции отлично укладывается в подобное определение.

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

Ну как же, при определённых параметрах у неё в стеке вызовов находится очевидный ad hoc код и согласно твоей позиции это должно означать, что и apply ad hoc. Или у нас снова двойные стандарты? Типа для my_equal_to применяем одни критерии, а для apply другие? ) Определись уже.

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

Ты сказать то хотел этой фразой? ) Видимо что-то очень остроумное. Настолько что смысл исчез вообще — расшифруй. )))

_>>Мда, похоже примеры с устройством Хаскеля реально слишком сложные. Давай проясним глупость твоих фраз (про "несколько тел для одной функции" и т.п.) на простейшем C++ примере, который аналогичен (если опять же собирать в отдельных бинарных модулях, а то иначе инлайнинг вообще убьёт все эти функции) внутреннему устройству Хаскеля:
_>>

_>>auto f=[](int x, int y) {return x+y;};
_>>auto g=[](int y) {return f(1, y);};
_>>f(1, 2);
_>>

_>>Так вот, по этому коду можешь ли ты сказать что:
_>>1. вторая строчка хоть как-то влияет на третью
S>Вряд ли.

О, прогресс.

_>>2. что компилятор генерирует несколько тел для функции f.
S>Ты же не показал 5ую и 10ю, в которых f(a, 2) * f(a, b) и передача f в какуюнибудь ФВП.

И снова от вершин на дно. Ты что, действительно думаешь, что это как-то изменит ситуацию? )

_>>И если не можешь, то почему говоришь аналогичный бред про случай с Хаскелем? )
S>Еще раз, согласно понятию процедурной абстракции можно подменять одно тело другим с сохранением поведения. И даже удалять тело, заменять его значением, или вообще выкидывать, если это не скажется на поведении. То что я написал что хаскель может это делать, отсюда совершенно не вытекает будто я утверждаю что он именно так делает.
S>Вот ты тут пугаешься что C++ выкинет твои функции. А ты уверен что хаскель не выкинет функцию apply, подменив ее вызовом f? Делает ли он вызов $ при каждом упоминании? Может ли это измениться с сохранением execution model? Я это допускаю. И это не влияет на классификацию полиморфизма.

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

)).

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

S>Так что с твоей оговоркой про поведение функций?

Ты вообще про что?

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

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

S>>Вот полная цитата из ответа vdimas-у, из которого ты вырвал понравившуюся фразу

_>Точно короткая память — я взял это не оттуда. )))
Оттуда, но ты взял лишь понравившийся тебе кусок.

S>>Учитывая выделенное "Но при том ее ad hoc природу не отнять" мне как-то сложно согласиться с "консесусом".

_>А мне кажется что в данном http://rsdn.org/forum/flame.comp/6678712.1 сообщение как раз наблюдается полный консенсус. )))
А мне не кажется

_>>>Что-то у тебя какая-то короткая память. Это как раз я неоднократно заявлял, что лично мне более чем достаточно факта параметрического полиморфизма на уровне исходного кода, а что там творится в машинных кодах вообще не принципиально. А ты наоборот начал говорить о важности анализа машинных кодов, чем мы и занялись. Правда в итоге оказалось, что в данной области ты очень слабо разбираешься, так что это твоё желание углубиться на уровень машинных кодов действительно очень странно. Но если ты посмотришь на историю сообщений в данной теме, то легко увидишь, что это было именно твоё желание.
S>>Да, ты такое заявлял. А я потом спросил, видел ли ты определение, которое довольствовалось бы лишь исходником. А к анализу машинных кодов все время ты склонял.

_>Это феерично.

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

S>>>>Не хочешь — не надо, я ж тебя не заставляю. Оставим просто как есть. Пирс, википедия, хаскельвики за ad hoc equal_to. Твое мнение никто не разделяет.
_>>>Ну а это уже откровенное враньё.
S>>Так опровергни

_>Ну так укажи где конкретно в данных источниках указано про необходимость анализа машинного кода (да ещё и всего стека вызовов).
Что, опять? Ты их уже поскипал разок.
http://rsdn.org/forum/flame.comp/6676499.1
http://rsdn.org/forum/flame.comp/6677933.1

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

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

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

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

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

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

_>>>2. что компилятор генерирует несколько тел для функции f.
S>>Ты же не показал 5ую и 10ю, в которых f(a, 2) * f(a, b) и передача f в какуюнибудь ФВП.

_>И снова от вершин на дно. Ты что, действительно думаешь, что это как-то изменит ситуацию? )
В чем?

_>>>И если не можешь, то почему говоришь аналогичный бред про случай с Хаскелем? )
S>>Еще раз, согласно понятию процедурной абстракции можно подменять одно тело другим с сохранением поведения. И даже удалять тело, заменять его значением, или вообще выкидывать, если это не скажется на поведении. То что я написал что хаскель может это делать, отсюда совершенно не вытекает будто я утверждаю что он именно так делает.
S>>Вот ты тут пугаешься что C++ выкинет твои функции. А ты уверен что хаскель не выкинет функцию apply, подменив ее вызовом f? Делает ли он вызов $ при каждом упоминании? Может ли это измениться с сохранением execution model? Я это допускаю. И это не влияет на классификацию полиморфизма.

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

)).
Есть, конечно. И не по-моему, а по процедурной абстракции.

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

S>>Так что с твоей оговоркой про поведение функций?

_>Ты вообще про что?

S>>Ad-hoc polymorphism, by contrast, allows a polymorphic value to exhibit diﬀerent behaviors when “viewed” at diﬀerent types.
S>>твоя my_equal_to абсолютно и полностью укладывается.

_>Не укладывается, т.к. поведение абсолютно одинаковое: вызов оператора равенства для соответствующего типа. )
Выше ты использовал понятие поведения функции в фразе "В этом случае на уровне машинных кодов появится отдельная функция с поведение как у apply f, но при этом она будет всего лишь обёрткой над apply."
Это как у тебя получилось что поведение обертки и функции одинаковое, притом что тут ты под поведением подразумеваешь лишь "вызов оператора"? Сам себя поймал, однако.

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

_>>>Это У тебя там что-то не то в тесте. Всё нормально преобразуется и инлайнится. )
_>>хз, http://rsdn.org/forum/flame.comp/6666169.1

_>Ну так ещё бы оно работало с выключенной оптимизацией. )))

Там не все так однозначно (c) даже с оптимизацией

clang — инлайнит оба варианта
gcc — вызов у стэк-объекта — инлайнит, вызов по указателю — нет, но вызов сам прямой
icc/cl — вызов по указателю — косвенный

_>>>Я тоже так думаю. Только откуда тогда возьмутся оптимизации в C#, про которые ты говорил?
_>>Я имел ввиду простой случай:
_>

_>A a = new A();
_>a.f();
_>

_>>где f — виртуальный метод

_>То, что в C# работает (кстати, ты это проверял, она точно работает?) хотя бы такая простейшая оптимизация, это уже хорошо.

мдя, зародил ты сомнения, и не зря, проверил — не работает (видимо я с чем-то другим спутал или проверял), проверил — НЕ работает, виртуальные методы всегда (A a = new A() локальное создание в методе, static readonly), проверил на нескольких вариантах джита, их щас 3 — x86/x64/x64-ryujit, вызываются косвенно.. печально

_>Но в гораздо более распространённом случае типа такого:
_>

_>A a = GetA();
_>a.f();
_>

_>она точно не сработает. В то время как в C++ наоборот она сработает со 100% гарантией (ну если конечно оптимизация включена

).

факт, в C#/.NET не сработает

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

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

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

_>>Это феерично.

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

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

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

_>>Ну так укажи где конкретно в данных источниках указано про необходимость анализа машинного кода (да ещё и всего стека вызовов).
S>Что, опять? Ты их уже поскипал разок.
S>http://rsdn.org/forum/flame.comp/6676499.1
S>http://rsdn.org/forum/flame.comp/6677933.1

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

_>>Во всех определениях используется нормальное понятие "код" или "кусок кода" и т.п. Т.е. речь о том, что мы берём конкретный код (машинный или исходный — не суть, хотя результаты могут быть разные) и говорим относится он к параметрическому полиморфизму или к 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 diﬀerent behaviors when “viewed” at diﬀerent types.
S>>>твоя my_equal_to абсолютно и полностью укладывается.
_>>Не укладывается, т.к. поведение абсолютно одинаковое: вызов оператора равенства для соответствующего типа. )
S>Выше ты использовал понятие поведения функции в фразе "В этом случае на уровне машинных кодов появится отдельная функция с поведение как у apply f, но при этом она будет всего лишь обёрткой над apply."
S>Это как у тебя получилось что поведение обертки и функции одинаковое, притом что тут ты под поведением подразумеваешь лишь "вызов оператора"? Сам себя поймал, однако.

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

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

_>Там не все так однозначно (c) даже с оптимизацией

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

_>clang — инлайнит оба варианта
_>gcc — вызов у стэк-объекта — инлайнит, вызов по указателю — нет, но вызов сам прямой

Т.е. по сути в контексте нашей дискуссии у них поведение одинаковое — различается стратегия инлайна..

_>icc/cl — вызов по указателю — косвенный

Хм, ну у cl то всё что угодно может быть (особенно в старых версиях). А вот насчёт icc странно — обычно он или наравне с gcc или чуть лучше. Хотя лично я им в последнее время не пользовался, т.к. разница в быстродействие с gcc обычно не принципиальная.

_>>То, что в C# работает (кстати, ты это проверял, она точно работает?) хотя бы такая простейшая оптимизация, это уже хорошо.
_>мдя, зародил ты сомнения, и не зря, проверил — не работает (видимо я с чем-то другим спутал или проверял), проверил — НЕ работает, виртуальные методы всегда (A a = new A() локальное создание в методе, static readonly), проверил на нескольких вариантах джита, их щас 3 — x86/x64/x64-ryujit, вызываются косвенно.. печально

Хы, ну не удивительно для JIT'a. ))) Можно ещё ради интереса проверить в .native — там вроде обещали некий компилятор с бэкендом от C++.

_>>Но в гораздо более распространённом случае типа такого:
_>>

_>>A a = GetA();
_>>a.f();
_>>

_>>она точно не сработает. В то время как в C++ наоборот она сработает со 100% гарантией (ну если конечно оптимизация включена

).
_>факт, в C#/.NET не сработает

Угу. И это только одно из многих последствий неверного изначального дизайна — слияния принципиально разных классификаций ссылочные/значения и классы/структуры. Хотя в той же Java ситуация ещё хуже. )))

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

Q>>Могут быть свои, могуть быть общие. В Visual Studio двигаются в сторону использования платформы Roslyn как для собственно компиляции, так и сервисов анализа кода.
V>8 лет пилить библиотеку парсинга C#...

И чтобы не так стыдно было — пустили пыль в глаза новым баззвордом "Compiler-as-a-Service"

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

EP>И чтобы не так стыдно было — пустили пыль в глаза новым баззвордом "Compiler-as-a-Service"

Если честно, не понимаю вашей хронической аллергии на C#. Ну да у каждого свои заскоки...

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

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

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

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

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

_>>>Ну так укажи где конкретно в данных источниках указано про необходимость анализа машинного кода (да ещё и всего стека вызовов).
S>>Что, опять? Ты их уже поскипал разок.
S>>http://rsdn.org/forum/flame.comp/6676499.1
S>>http://rsdn.org/forum/flame.comp/6677933.1

_>В данные цитатах нет ни одного слова про подобное. Или у тебя своё особое понимание и английского языка?
Особое от твоего — точно. Я вот в этих определениях не увидел ничего про "тело функции". А ты — увидел.

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

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

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

EP>>И чтобы не так стыдно было — пустили пыль в глаза новым баззвордом "Compiler-as-a-Service"

S>Если честно, не понимаю вашей хронической аллергии на C#. Ну да у каждого свои заскоки...

Не понимаю твоей хронической аллергии на коньяк по утрам. Ну да у каждого свои заскоки...

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

S>>Если честно, не понимаю вашей хронической аллергии на C#. Ну да у каждого свои заскоки...

EP>Не понимаю твоей хронической аллергии на коньяк по утрам. Ну да у каждого свои заскоки...

Когда язык программирования сравнивают с алкоголизмом — это сильно. Только вот алкоголик в данной аналогии — вы, а коньяк по утрам — CPP. А в остальном всё верно

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

V>Предлагаю завязывать, бо мне уже трудно сдерживать откровенное глумление...
Да уж... "Ха-ха! На самом деле это был ТЕСТ!!! И вы его НЕ ПРОШЛИ!!111"

... Образец здравомыслия просто.

V>Столько было пафоса и такой пффф... Не могу отучить себя реагировать на такую комбинацию ))
Извините, давно читали свои сообщения? Ощущение, что круг вашего общения ограничен исключительно форумом.

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

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

Тогда 3 уточняющих вопрос:
1. Т.е. у тебя нет разделения на полиморфизм на уровне исходного и машинного кода и ты всегда выводишь для функции объединение обоих критериев (я предпочитаю рассмотреть отдельно на каждом уровне и озвучивать для каждой функции два отдельных результата)?
2. Т.е. под фразой "будет ли выполняться различный код для каждого типа" ты подразумеваешь сравнение машинного кода функции, генерируемого для каждого типа или же что-то другое?
3. Если в пункте 2, ты говорил про машинный код, то подразумеваешь только сравнение тела функции или же добавляешь к этому ещё и сравнение машинного кода всех других функций из стека вызова нашей?

S>>>http://rsdn.org/forum/flame.comp/6676499.1
S>>>http://rsdn.org/forum/flame.comp/6677933.1
_>>В данные цитатах нет ни одного слова про подобное. Или у тебя своё особое понимание и английского языка?
S>Особое от твоего — точно. Я вот в этих определениях не увидел ничего про "тело функции". А ты — увидел.

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

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

На низком уровне различный код исполняется всегда (хотя бы потому что ЦПУ у нас по сути ad hoc). И соответственно если следовать твоей логике, то само понятие параметрического полиморфизма теряет смысл для подавляющей части реального кода.

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

Это согласно моей точки зрения. И так же согласно твоим отдельным заявлениям. А теперь (когда ты конкретизируешь те 3 пункта в начале сообщения) мы посмотрим получается ли тоже самое из твоего определения критериев. И соответственно если не получится, то будем в очередной раз громко смеяться.

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

Ты снова путаешь свои взгляды и мои?) В моих как раз на поведение apply ничего не влияет. )

А по поводу аналогии очевидно же. Возьмём мой пример my_equal_to на C++. Он использует некий тип eq, который как раз и осуществляет изоляцию ad hoc кода в себе, так что вызов его оператора равенства из my_equal_to получается параметрически полиморфным (такой оператор опять же ровно один для всех типов, и в исходных кодах и в машинных).

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

Непонятно зачем ты постоянно приплетаешь данный термин из области методологии разработки ПО. У нас же вроде как чисто техническая дискуссия.

Да, и кстати, ещё непонятно зачем ты его пишешь по английский, хотя это полная древность, имеющая очевидную запись на русском языке.

S>

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

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

Ээээ что? ) У меня такое впечатление, что ты хочешь сказать, что слово "поведение" является каким-то программистским термином, а не просто общеупотребимым словом с очевидным значением. Если ты реально так считаешь, то я буду рад, если ты и меня просветишь в этом вопросе (естественно со ссылками на определение данного "термина"). А то мало ли, вдруг я действительно не в курсе и такой интересный термин реально существует...

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

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

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

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

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

Вообще то мне известно всего одно значение слова "поведение" (причём и оно то не "компьютерное"), так что использовать какие-то два его смысла я бы не смог физически. )

	От:	vdimas
	Дата:	31.01.17 09:16
	Оценка:

	От:	vdimas
	Дата:	31.01.17 09:22
	Оценка:

	От:	Evgeny.Panasyuk
	Дата:	31.01.17 15:34
	Оценка:

	От:	Ops
	Дата:	31.01.17 15:43
	Оценка:

От:	samius	http://sams-tricks.blogspot.com
Дата:	31.01.17 19:09
Оценка:

От:	netch80	http://netch80.dreamwidth.org/
Дата:	05.02.17 21:46
Оценка:

	От:	alex_public
	Дата:	01.02.17 14:45
	Оценка:

	От:	alex_public
	Дата:	01.02.17 20:51
	Оценка:

	От:	pilgrim_
	Дата:	04.02.17 00:28
	Оценка:

	От:	alex_public
	Дата:	04.02.17 01:43
	Оценка: