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

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

S>>Нет, такого разделения я не делаю. И не знаю никого, кроме тебя и vdimas-а, кто бы так делал. И объединение обоих критериев я тоже не использую. Я смотрю на поведение.

_>Я вижу смысл в таком разделение по той причине, что имеются языки с разным видом полиморфизма на уровне исходного кода и на уровне машинного. Т.е. очевидно параметрически полиморфная функция на уровне исходного кода, может иметь ad hoc реализацию (причём программист может об этом даже не знать, как часто бывает например в том же Хаскеле) на уровне машинных кодов.
У исходного кода без execution model нет поведения, т.е. говорить не о чем, только об факте включения некоторого подтекста. Но при рассмотрении текста в совокупности с execution model, получается поведение и однозначная классификация полиморфизма по поведению.

_>Но я естественно не настаиваю на том, чтобы мои собеседники тоже пользовались подобным разделением. Это я просто пояснил причины такого подхода.
Спасибо, но что-то я замечаю некоторую тавтологию. Ты вводишь полиморфизм исходного и полиморфизм машинного лишь для того что бы иметь возможность говорить о том что функции ведут себя одним образом на уровне исходников и другим на уровне машинных кодов. А зачем тебе такое — ты не поясняешь. Чего ради-то?

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

_>>>2. Т.е. под фразой "будет ли выполняться различный код для каждого типа" ты подразумеваешь сравнение машинного кода функции, генерируемого для каждого типа или же что-то другое?
S>>Зачем сравнение машинного кода?

_>Как это зачем? Ты же сам в предыдущем сообщение чётко ответил, что одного анализа исходного кода недостаточно. А если недостаточно анализа исходного кода, то что ещё остаётся то? Только генерируемый по нему машинный... Или ты знаешь ещё что-то, что можно проанализировать у некого "куска кода"? )
Знаю, но уже не знаю, как тебе об этом сказать. Пытаюсь, но ты все время думаешь что я что-то скрываю.

S>>Достаточно знать, будет ли вызван специфический для типа код. Догадаться об этом можно по execution model или даже по весьма приблизительным представлениям о ней.

_>Ну т.е. получается что всё же исходников достаточно? ))) Или как? )
В совокупности с execution model — наверняка.

S>>Есть надежда что по вышеописанному у тебя схожая позиция.
S>>Так вот, проверка наличия вызова специального кода для параметра типа — она ничем не отличается от вышеописанной проверки по возбуждению исключения либо проверки на обращение к h.

_>О, великолепный пример. Хотя конечно же всем известно, что аналогия не является доказательством. Но тут она так красиво демонстрирует именно мою точку зрения, что прямо не могу удержаться. И так, смотри на такой простейший код:
_>

_>void f() {throw "Ou!";}
_>void g() {try{ f(); }catch(...){}}
_>void h() {g();}
_>

_>Теперь внимание фокус:
_>Вопрос: происходит ли в процессе выполнения функции h возбуждение исключений (читай: происходит ли в процессе выполнения my_equal_to исполнение ad hoc кода?)?
_>Ответ: да.
_>Вопрос: является ли функция h источником исключений (читай: является ли функция my_equal_to ad hoc полиморфной?)?
_>Ответ: нет.
То есть ты взял и один вопрос, ответ на который требует просмотра всего ветвления, якобы "по аналогии" подменил на другой вопрос, ответ на который не требует просмотра всего ветвления (как минимум, в частном случае). Неплохо, но я не прослеживаю в твоем примере аналогиии с проверкой на факт выполнения некого специального кода. Зубы заговариваешь?

_>Ну и для полной ясности аналогии уточню: f=="операторы равенства всех типов", g=="оператор равенства для eq", h==my_equal_to.

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

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

_>>>Ха, так я то как раз не пытаюсь прятаться за чужие цитаты, а говорю именно свою точку зрения. Но при этом она неплохо совместима с этими известными цитатами. А вот ты наоборот пытаешься сделать вид, что высказываемый тобой бред является прямым следствием из этих цитат, хотя в них нет ничего даже отдалённо похожего.
S>>Интересно, на что по-твоему похожа фраза "function may execute different code for each type of argument"? Опиши, пожалуйста, своими словами, не отрываясь от своей теории полиморфизма в тексте. Приведи примеры функций, которые обладают и не обладают данным свойством.

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

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

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

Prelude> just a = Just a
Prelude> :t just
just :: a -> Maybe a

Еще одну?

S>>Термин-то обычный бытовой. Но имеет значение, чего именно поведение ты рассматриваешь. Говоря о поведении функции, имеет смысл рассматривать поведение именно функции, а не переходить к подробностям ее реализации на определенной платформе определенной версии компилятора с определенными опциями.

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

так что использовать какие-то два его смысла я бы не смог физически. )

А тут уже в любых. Рад за тебя.

S>>Возвращаясь к поведению my_equal_to — оно разное в зависимости от разных типов. Я говорю здесь о поведении функции, о свойствах отображения, если переводить на язык математической абстракции. А не о том, что она вызовет и вообще вызывает ли.

_>Поведение как раз одинаковое — см. ниже.
Не ну чушь. У сравнения поведение разное для разных типов.

_>>>Да, ну и напоследок. Если так случилось, что контракт функции по сути оказался полным описанием её внутреннее реализации, то это всего лишь свидетельствует о крайней простоте (ну обёртка и есть обёртка) этой функции. А не об использование деталей реализации в описание контракта.
S>>Вот смотри (цитата с http://www.cplusplus.com/reference/string/char_traits/eq/)
S>>

S>>Returns whether characters c and d are considered equal.

S>>In the standard specializations of char_traits, this function behaves as the built-in operator==, but custom character traits classes may provide an alternative behavior.

S>>Перевести тебе выделенное? Здесь пишут что "эта функция ведет себя как встроенный оператор ==". Они пишут не о том, как ведет себя реализация функции (что она там вызывает). Они пишут о схожем поведении с чем-то еще. Если бы они сказали что eq что-то вызывает, а не ведет себя подобнымм образом, пришлось бы скрывать то что она ведет себя подобным образом, ибо реализация == может уже третьего оператора не вызывать. Итого, факт вызова — это не касается поведения функции. Это за гранью procedural abstraction.

_>Вообще то сомнительная цитата (см. ниже), но если тебе очень хочется говорить именно в таких терминах, то никаких проблем нет — я могу сформулировать и в таких. И так правильная формулировка в таких терминах: функция my_equal_to ведёт себя как оператор равенства класса eq.
ты не договорил. Она ведет себя так же как eq — то есть по разному, в зависимости от типа. Иными словами — специальным образом (ad hoc).

S>>То есть ты со своим вниманием к мелкой оптимизации просто выпал из терминов, на котором описаны функции в cplusplus.com. Или там кто-то поработал из секты свидетельства ad-hoc полиморфизма. Потому, тебе придется и их вычеркнуть из списка доверенных источников, если уже не выкинул, как хаскельвики.

_>Хы, вообще то cplusplus.com действительно давно протух и все знакомые с C++ программисты давным давно пользуются этим http://en.cppreference.com/w/cpp/string/char_traits/cmp (кстати можешь сравнить формулировку здесь и твою цитату) ресурсом. Но на нашу дискуссию данный факт никак не влияет, т.к. твои мелкие цепляния к формулировкам никак не меняют суть происходящего. )))
Ощутимой разницы в формулировке не нашел, наверное и cppreferencce.com тоже протух. Итого, получается что твоей точке зрения способствует лишь весьма своеобразная трактовка фразы "function may execute different code for each type of argument". Все остальное (хаскельвики, википедия, cpp ресурсы) — по-твоему тухлое. Но ты — весь в белом. И это тоже не меняет суть происходящего, а есть сама суть.