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

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

S>>Вот, именно что выглядит "как".

V>А только это и важно.
Кому как

V>Т.е., с одной стороны, у нас есть некий уровень реализации полиморфизма с т.з. программиста:
V>- перегрузка имен ф-ий;
V>- виртуальные ф-ии;
V>- параметрический полиморфизм некоторого ранга (туда же обязательный автовывод типов при ранге большем 1, иначе такой полиморфизм будет неюзабелен).
согласен

V>С другой стороны есть механики его обеспечения компилятором — матчинг типа и соответствующей ему ф-ии/метода на этапе компиляции/оптимизации или на этапе исполнения через таблицу ф-ий, как для случая виртуальных ф-ий в ООП или в некоторых сценариях с использованием классов типов в том же Хаскеле.
верно. Но цитата из Пирса однозначно отсылает к механике выполнения в рантайме. И если интерпретатор, рантайм, или еще кто выполняет разные версии кода для разных типов, то это ad hoc.

S>>Класс типов осуществляет диспетчеризацию статически, сводя параметрический и ad hoc полиморфизм в единую модель.

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

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

V>Например, в классике ООП:
V>

V>foreach(Vidget v in vidgets)
V>  v.Draw(context);
V>

V>- динамический ad hoc полиморфизм на виртуальной ф-ии Draw.
+1

V>А вот здесь:
V>

V>Rectangle r = new Rectangle(bounds);
V>r.Draw(context);
V>

V>хороший компилятор должен должен будет вставить прямой вызов Draw, а не виртуальный, т.е. имеем статический ad hoc полиморфизм.
+1

V>По-сути мы зацепились вокруг того, что хотя компилятор C# в 99% случаев был бы способен разресолвить параметрический полиморфизм на этапе компиляции (т.е. приведя его к ad hoc через вывод монотипов, прямо как на шаблонах С++), однако же, ради "экономии" размера бинарника всё будет сведено к динамическому ad hoc-полиморфизму на основе виртуальных вызовов типов-ограничений (интерфейсов или абстрактных/виртуальных баз).
не вполне распарсил выделенное
А то что компилятор C# был бы способен многое — это верно.

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

V>Разные виды полиморфизма ни в коем случае не ортогональны друг другу, а часто друг через друга выражаются или некие случаи представляют из себя одновременно несколько разновидностей полиморфизма. Поэтому, ИМХО, — это рассуждения вникуда, когда пытаются один вид полиморфизма "тщательно отделить" от другого.
Не вполне согласен. Есть чистые случаи (пусть они крайности), есть комбинированные.

V>Еще раз. "Полиморфизм" в общем смысле — он ровно один, означает способность ЯП автоматически сопоставлять конкретные одноимённые ф-ии/методы (или операторы, что тоже есть ф-ии) конкретным типам, что позволяет программисту делать меньше работы, т.е. полиморфизм повышает выразительность языка. Но степень подобной "автоматизации" и её рантайм-цена у разных языков разная.
Хорошо, тут не с чем спорить.


S>>Но он параметрический лишь до той степени, пока не потребуется взять тип, не удовлетворяющий ограничению. В то время как кошерно параметрический код не требует от этого типа более ничего.

V>Ну как это "ничего"? Мы с "самого низа" используем ну хотя бы операторы языка. Операторы — это тоже ф-ии, язык с хорошей поддержкой полиморфизма должен позволять определять семантику этих операторов для различных типов или их классов. Например, в Хаскеле предопределены некоторые базовые классы типов, необходимые для использования операторов языка: Eq, Ord, Num, Real, Integral, Monad или для базовых операций преобразования в строку — Show. Т.е., совсем "из ничего" не получится.
Вот все что я выделил — это https://wiki.haskell.org/Polymorphism#Ad-hoc_polymorphism
С этим есть разногласия? А я говорил о параметрическом.

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

V>А вот не надо пытаться тщательно отделять мух от котлет, когда речь о полиморфизме. ))
V>Потому что это зачастую банально невозможно.
Что тут сложного? equal_to — ad hoc, Eq a — ad hoc. Но если внезапно из рассмотрения выкинуть все типы, кроме тех, у которых определен оператор == или инстанс Eq, то тогда они выглядят как параметрические.

V>Как конкретный тип может иметь одновременно признаки разных классов, так и конкретный сценарий полиморфизма может одновременно быть случаем совместной работы разных "трюков" обеспечения полиморфизма или даже одновременно являться любым из некоего множества "трюков" в их граничных/частных ситуациях.