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

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

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

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

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

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

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

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

Ну т.е. получается что всё же исходников достаточно? ))) Или как? )

_>>3. Если в пункте 2, ты говорил про машинный код, то подразумеваешь только сравнение тела функции или же добавляешь к этому ещё и сравнение машинного кода всех других функций из стека вызова нашей?
S>Хорошо, если даже я не говорил в пункте 2 о машинном коде, то execution model может предполагать стек вызовов. И поэтому можно поговорить и о стеке. Тут я предлагаю на минуту отвлечься от критериев полиморфизма и рассмотреть некое свойство функции g, например, может ли случиться исключение при выполнении g, или обращается ли g к функции h? Если g — обычная функция (не ФВП), то ответ для нее получить довольно просто. Достаточно рассмотреть все ветвления при исполнении. Если мы там обнаружим вызов h или нечто, что может возбудить исключение, станет очевиден ответ на вопрос для функции g. Если g есть ФВП, то поиск ответа становится менее очевиден. Для ответа не достаточно найти функцию f, что g(f) укажет на выполнение h или возбуждение исключения. Хорошо бы еще либо найти такую p, что g(p) не даст такого ответа, либо убедиться что такой функции не существует.
S>Так вот, если мы нашли такую f, что g(f) возбуждает исключение и p что g(p) не возбуждает, то это как бы намекает на то, что сама g не обладает проверяемым свойством, что оно наведенное переданным параметром.
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 нельзя определить без уточнения её параметров, правильно?

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

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

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

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

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

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

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

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

Хы, вообще то cplusplus.com действительно давно протух и все знакомые с C++ программисты давным давно пользуются этим http://en.cppreference.com/w/cpp/string/char_traits/cmp (кстати можешь сравнить формулировку здесь и твою цитату) ресурсом. Но на нашу дискуссию данный факт никак не влияет, т.к. твои мелкие цепляния к формулировкам никак не меняют суть происходящего. )))