В этом PDF-презентации в классах классов Haskell в слайде # 54 есть этот вопрос:
Открытый вопрос:
На языке с дженериками и ограниченный полиморфизм, вам нужно тоже подтипирование?
Мои вопросы:
Как общие и ограниченный полиморфизм делают ненужным подтипирование?
Если generics и ограниченный полиморфизм делают ненужным подтипирование, почему Scala имеет подтипирование?
Олег Киселев и Ральф Леммел "Haskell упустил объектную систему" предлагает библиотеку для Haskell, которая реализует объектную систему с использованием существующих функций Haskell, включая типа.
Отрывок из раздела "Введение" в документе (выделено мной):
Интерес к этой теме вовсе не ограничивается исследователями и практиками Хаскелла, поскольку существует фундаментальный и нерешенный вопрос - вопрос, который рассматривается в настоящей статье:
Какова связь между полиморфизмом с ограниченным типом и подтипом?
В этом контексте исследования мы определенно (и решительно) ограничимся существующий язык Haskell (Haskell 98 и общие расширения, где это необходимо), то есть никаких новых расширений Haskell не предлагается. Как мы будем доказывать, это ограничение является адекватным, поскольку оно позволяет нам дать осмысленный и важный ответ на вышеупомянутый вопрос.
Как общие и ограниченный полиморфизм делают ненужным подтипирование?
Неизвестно, что они делают. Если вы помещаете слайд в контекст, я думаю, что аргумент, который пытался сделать оратор, выглядит примерно так:
В старые времена подтипирование обеспечивало важный вид полиморфизма.
Также в старые времена в другой стране типы абстракции и параметры типа обеспечивали важный вид полиморфизма. Этот вид известен на его родине как параметрический полиморфизм, но в чужих странах он называется дженериками.
Современные дженерики допускают ограничения, иногда называемые "ограниченным полиморфизмом", которые могут достигать многих из тех же вещей, что и полиморфизм подтипа.
Подтипирование несет в себе существенный багаж, в частности, вам нужно беспокоиться о ковариации и контравариантности. Языки заканчиваются неудобными ограничениями, тяжелыми обозначениями, а иногда и откровенными нарушениями безопасности (например, Eiffel).
Открытый вопрос: возможно, ограниченный параметрический полиморфизм решает достаточно те же проблемы, что и в счастливое будущее, мы можем полностью избавиться от полиморфизма подтипа, а вместе с ним и неприятный вопрос о том, что подтипирование является ковариантным, контравариантным и инвариантным.
Хорошо, если это действительно открытый вопрос, то по определению мы не знаем ответа на # 1. Конструктивные пространства довольно разные, и для меня не очевидно, как вы можете напрямую кодировать подтипирование в ограниченный полиморфизм. Кодирование является прямым, когда аргументы являются полиморфными. Например, функция Haskell с типом
foo :: (Num a) => a -> Bool
эквивалентно, скажем:
Bool foo(Num x)
на языке OO. Однако неясно, как кодировать:
// I will return some Num, but I'm not going to tell you what kind exactly
Num bar(Bool x)
в ограниченный полиморфизм, и не ясно, как кодировать:
-- I can return any kind of Num, *you* tell *me* what kind
bar :: (Num a) => Bool -> a
в подтипирование.
Мое лучшее предположение для № 2 заключается в том, что Scala должен разговаривать с Java, а Java говорит о подтипировании. И поскольку Scala имеет любую функцию системы, известную человеку, потому что она думает, что она должна быть крутой.:-P
2 легко: потому что Java (и JVM байт-код) имеет его. Если мы хотим с пользой называть Scala с Java, мы в значительной степени должны разрешать расширение интерфейсов и классов Java; и если классы Scala переходят в классы JVM (и черты к интерфейсам), мы также можем их расширить.
По той же причине, почему Scala имеет null:)
Что касается 1, вам также необходимо иметь экзистенциальные типы для кодирования
Num bar(Bool x)
так:
bar :: Bool -> exists a. Num a