Контрастирование дженериков C# с Haskell параметризовало типы

Мы можем сделать другие вещи с классами типа Haskell слишком теперь. Поиск с помощью Google для "дженериков" в Haskell открывает целое поле более высокого разряда полиморфное универсальное программирование вне стандартного параметрического полиморфизма, о котором большинство людей думает как "дженерики".

Например, GHC недавно получил семейства шрифтов, включив все виды интересных возможностей программирования типа. Очень простым примером являются решения представления данных на тип для произвольных полиморфных контейнеров.

Я могу сделать класс для, говорят, списки,

class Listy a where

    data List a 
             -- this allows me to write a specific representation type for every particular 'a' I might store!

    empty   :: List a
    cons    :: a -> List a -> List a
    head    :: List a -> a
    tail    :: List a -> List a

Я могу записать функции, которые воздействуют на что-либо, что инстанцирует Списка:

map :: (Listy a, Listy b) => (a -> b) -> List a -> List b
map f as = go as
  where
    go xs
        | null xs   = empty
        | otherwise = f (head xs) `cons` go (tail xs)

И все же мы никогда не давали конкретный тип представления.

Теперь, когда класс для универсального списка. Я могу дать особые хитрые представления на основе типов элемента. Так, например, для списков Интервала, я мог бы использовать массив:

instance Listy Int where

data List Int = UArray Int Int

...

Таким образом, можно начать делать некоторое довольно мощное универсальное программирование.

В продолжение «вы можете столкнуться с большими проблемами, думая, что концепция, с которой вы знакомы на одном языке, совпадает с другим языком [в котором вы новичок]» часть этого вопроса:

Вот ключевое отличие (скажем, от Ruby), которое вы должны понимать, когда используете классы типов Haskell. Для такой функции, как

add :: Num a => a -> a -> a
add x y = x + y

. Это не означает, что x и y оба являются любыми типами класса Num . Это означает, что x и y относятся к одному и тому же типу, который относится к классу Num . «Ну, конечно, вы говорите; a то же самое, что a ». Что я тоже говорю, но мне потребовалось много месяцев, чтобы перестать думать, что если бы x было Int , а y было Integer , это было бы как добавление Fixnum и Bignum в Ruby. Скорее:

*Main> add (2::Int) (3::Integer)

<interactive>:1:14:
    Couldn't match expected type `Int' against inferred type `Integer'
    In the second argument of `add', namely `(3 :: Integer)'
    In the expression: add (2 :: Int) (3 :: Integer)
    In the definition of `it': it = add (2 :: Int) (3 :: Integer)

Другими словами, подклассы (хотя оба экземпляра Num , конечно, также являются экземплярами Eq ) и утиная типизация исчезли, детка.

Звучит красиво. простой и очевидный, но требуется некоторое время, чтобы научиться понимать это инстинктивно, а не просто интеллектуально, по крайней мере, если вы пришли из многолетнего опыта Java и Ruby.

И нет, как только я овладею этим , Я немного не скучаю по подклассам. (Ну, может быть, время от времени немного, но я приобрел гораздо больше, чем потерял. И когда я действительно скучаю по этому,

Еще одно большое отличие состоит в том, что универсальные шаблоны C # не допускают абстракции над конструкторами типов (т.е. видами, отличными от *), в то время как Haskell это делает. Попробуйте перевести следующий тип данных в класс C #:

newtype Fix f = In { out :: f (Fix f) }