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

_>>Моё мнение основано на:
_>>- знание определения понятия "параметрический полиморфизм" и целей его возникновения
S>Знаю, но никому не скажу, особенно про источник.

Вообще то несколько раз уже тут озвучивал. Но если ты так и не смог этого увидеть, то озвучу ещё раз, выделено:

Параметрический полиморфизм — это механизм, позволяющий обрабатывать значения разных типов с помощью одного и того же программного кода.

Подходит такое или и тут будешь спорить? )

_>>- знание всех деталей работы шаблонов C++
_>>- знание устройства полиморфизма в Хаскеле (для сравнения), ну и кстати дженериков в Java/C# (это разве для того чтобы посмеяться, т.к. самая убогая реализация из всех упомянутых) тоже.
_>>Этого более чем достаточно для подобных выводов.
S>Кому — как. Мне этого не достаточно что бы принять твои выводы.

А про тебя никто и не говорил. Для тебя были представлены соответствующие аргументы.

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

Ну например потому, что подобные техники оптимизации ради быстродействия применяют и в ML языках (про которые обычно никто не спорит насчёт наличия параметрического полиморфизма). Загляни например сюда http://mlton.org/References.attachments/060916-mlton.pdf. Особенно мне нравится там один термин, который можно увидеть в заголовке 12-го слайда. Он как раз очень хорошо описывает внутреннюю реализацию шаблонов C++.

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

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

S>>>А откуда требование "для многих"?
_>>Из определения понятия "полиморфизм". )))
S>Ты боишься что ли привести определение, которое знаешь и которым пользуешься?

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

_>>>>Т.е. если я напишу на Хаскеле функцию f вида "f a = xrmbrm a", то она по твоему обязательно будет работать для всех типов? )))
S>>>может быть и для всех, если у нас "xrmbrm = id"
S>>>а может и не для всех. Она возьмет ограничения из определения xrmbrm
_>>Совершенно верно. И какую ты тут видишь разницу со случаем equal_to (заменяем его на f, а оператор равенства на xrmbrm)?
S>никакой.

Т.е. я правильно тебя понял, что возможность написать в Хаскеле функцию вида "f a = xrmbrm a" является проявлением ad hoc полиморфизма? )))

S>Потому и заявляю, что equals_to — ad hoc, т.к. требует специализации чуть ли не для всех типов.

Ну давай, расскажи, зачем может понадобиться специализация equals_to.