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

Лол. А кто-то разве утверждал, что это уникальная фича Haskell?

Но ведь полиморфизм относится к семантической составляющей языка, а проверка типов — к вопросам реализации. какой смысл рассматривать полиморфизм в отрыве от семантики?

linearisation было лучше :-)

какой же ник будет следующим? :) в любом случае, узнаем быстро

В любом статически-типизированном языке, где есть функция map, есть и параметрический полиморфизм. Кроме C++.

дежавю: http://www.cyberforum.ru/haskell/thread1903610.html

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

Вообще, я как бы старался быть политкорректным, и не выдвигать провокационные тезисы, но, по секрету говоря, я не считаю, что то что есть в хаскеле, и, даже в статическом ООП полиморфизмом вообще. Это жалкая пародия. Истинный полиморфизм может быть только в динамических ООП-языках, где типы являются первоклассными объектами. Но, будем придерживаться «общепринятой» терминологии, конструктива ради

ну можно сказать наоборот: что существуют различные виды полиморфизмов. полиморфизм поведения (трейтов времени компиляции), задаваемых этими самыми параметрами. поведение=различные типы связей (вспоминаем UML: наследование, ассоциации, агрегации, композиции, зависимости, включения). в стиле разные «типы связи», трейты поведения=тайпклассы в хаскеле. наследование один из них.

то есть наоборот то, что «полиморфизм наследования» это всего лишь один из более обобщённого полиморфизма полиморфизмов, метаполиморфизма или «параметрического полиморфизма» абстрактного поведения, абстрактных типов связи.

в ООП вообще-то 5 типов связей (стрелок в UML), включая наиболее абстрактные ассоциации (между типами времени компиляции) и зависимости (между объектом в рантайме и типами времени компиляции), например. а не только наследование (и «полиморфизм наследования»).

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

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

то есть, модель синтезируется гарантированно корректная по типам в рантайме. за счёт более широких типов в компайл тайме.

в отличие от «полиморфизма в динамическом ООП с first-class objects, метаклассами и функциональными объектами».

утиная типизация (проверяемая в рантайме) vs. статической, проверяемой в компайл-тайме (за счёт расширенных типов, и расширенных полиморфизмов, в конкретном а не произвольном «динамического ООП» смысле).

если к примеру, динамическое ООП и его полиморфизм «в рантайме» разумно ограничить (чем-то рефлексивным типа mirrors в newspeak, компилируемом смоллтоке от Gillad Bracha, проверяемым во время компиляции) — то параметрический полиморфизм (произвольного поведения, типа связей = задаваемый параметром-трейтом тайпклассом) и получится.

полезный пример "параметрического полиморфизма"

evilml — шуточный (но рабочий) пример транслятора ML -> C++

1) вводим в одно окно параметрически параметризированный код на ML/Ocaml.

2)нажимаем «Compile» и получаем нечитаемое С++ говно на шаблонах (если случайно код получился всё ещё читаемый, ставим галочку [x] embedding evilml.hpp и жмём опять)

3) ... ??? ....

4) PROFIT!!!