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

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

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

_>Кстати, в C++ имеется своя, полностью безопасная техника стирания типа: http://www.boost.org/doc/libs/1_63_0/doc/html/boost_typeerasure.html. И с помощью неё можно элементарно написать аналог equal_to, который будет демонстрировать параметрический полиморфизм не только на уровне исходного кода, но и на уровне машинного:
вот тут я по поводу машинного не согласен.
Ты Вадлера88 посмотрел? Ввел он типы классов, перестало быть сравнение ad hoc? Нет, статья прям и называется "Как из ad hoc сделать меньше ad hoc". Т.е. типы классов в Хаскеле — ad hoc, как ни крути, но в меньшей степени, чем перегрузка. И это не я придумал.

_>В данном случае функция my_equal_to так же работает с любыми типами имеющими оператор равенства, но при этом она полностью изолирует ad-hoc природу этого оператора внутри себя — она имеет единый и исходный и машинный код для всех типов. По сути похоже на работу внутренностей Хаскеля. И такое же медленное (без всякого инлайнинга). Так что в мире C++ этот механизм используется только для очень специфических целей.
Я верю тебе что transform перестает умножаться в таком случае. Но для float и int будет вызываться все же одна машинная инструкция? Или все-таки разные за счет косвенности? Если разные — значит ad hoc (см Wadler88).

S>>На природу equal_to не влияет, но раздувает transform.

_>В шаблонах C++ — да. В других реализациях (см. например выше) — необязательно. Т.е. основная моя мысль в том, что указанное распухание кода является свойством (является ли оно ужасной проблемой или же важным преимуществом — это другой вопрос) именно шаблонов C++, а не обязательным следствием взаимодействия параметрического и ad-hoc полиморфизма. В других реализациях ad-hoc часть вполне себе изолируется и никак не влияет на другие уровни.
Согласен. Но с оговоркой что ad-hoc не перестает быть ad-hoc-ом.

S>>Ты вообще согласен что Eq a — это ad hoc (о чем написано на каждом заборе)? Если да, то как ты объяснишь свое желание считать equal_to параметрическим, хотя он в большей мере ad hoc, о чем писал Wadler?

_>Eq a в данном примере является аналогом не equal_to, а всему множеству операторов равенства в данном C++ проекте. ))) А прямой аналог equal_to вряд ли встретится на практике (хотя пишется элементарно) в Хаскеле и ему подобных языках, просто потому что в отличие от C++ данное мелкое украшательство может оказаться не бесплатным. Кстати, бесплатные многоуровневые абстракции — это как раз одна из ключевых особенностей современного C++.
Я имел в виду аналог семантический, а не по реализации. В плане реализации, видимо, Eq a более смахивает на bool my_equal_to, если я правильно понял.
А бесплатного ничего не бывает.

S>>Это не миф, это результат моего опыта. Да, я в разной степени владею C# и C++. И именно в моем случае скорость развития С++ проекта в разы медленнее, чем скорость развития схожего по сложности проекта на C#.

_>А, ну если ты только про себя говоришь, то всё может быть. Более знакомым инструментом частенько можно добиться лучших результатов. Даже если сам инструмент хуже по своей природе. )
Исключительно про себя.

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

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

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