Почему не ограничен подклассом Enum в Haskell

Кажется, что у любого ограниченного экземпляра должна быть нормальная реализация Enum. Лично я не могу придумать контрпример, хотя, если кто-то придумает такой, который не является патологическим, я пойму, почему это не так.

Из :iэтих двух классов типов кажется, что единственное исключение в стандартной библиотеке в настоящее время относится к кортежам, которые являются ограниченными, но не перечислимыми. Однако любой ограниченный кортеж также должен быть вменяемым Enumerable, просто увеличивая последний элемент, а затем оборачиваясь, когда он достигает maxBound.

Это изменение, вероятно, также будет включать добавление predBи nextBили что-то в этом роде в Bounded для безопасного / циклического способа обхода значений Enum. В этом случае toEnum 0 :: (...)будет равно(toEnum 0, toEnum 0, ...) :: (...)

Мне нравится один практический пример из мира языков программирования: набор типов в ОО-системе ограничен и дискретен, но не перечислим, а частично упорядочен, но не полностью упорядочен.

Рассматриваемый частичный порядок является отношением подтипов <:. Верхняя граница будет тогда верхним типом (который вызывает C # objectи Scala Any), а нижняя граница будет нижним типом (Scala Nothing; у C # / Java нет эквивалента, о котором можно говорить).

Однако нет способа перечислить все типы в системе типов, поэтому вы не можете написать instance Enum Type. Это должно быть понятно: пользователи могут писать свои собственные типы, поэтому нет никакого способа узнать, кем они будут заранее. Вы можете перечислить все типы в любой данной программе, но не во всей системе.

Точно так же (согласно определенному разумному определению подтипа) <:рефлексивно, транзитивно и антисимметрично, но не полностью . Есть пары типов, которые не связаны с <:. ( Catи Dogоба являются подтипами Animal, но ни один не является подтипом другого.)

Предположим, что мы пишем компилятор для простого языка OO. Вот представление типов в нашей системе:

data Type = Bottom | Class { name :: String, parent :: Type } | Top

И определение отношения подтипа:

(<:) :: Type -> Type -> Bool
Bottom <: _ = True
Class _ _ <: Bottom = False
Class n t <: s@(Class m _)
    | n == m = True  -- you can't have different classes with the same name in this hypothetical language
    | otherwise = t <: s  -- try to find s in the parents of this class
Class _ _ <: Top = True
Top <: Top = True
Top <: _ = False

Это также дает нам отношение супертипирования.

(>:) :: Type -> Type -> Bool
t >: s = s <: t

Вы также можете найти наименьшую верхнюю границу двух типов,

lub :: Type -> Type -> Type
lub Bottom s = s
lub t Bottom = t
lub t@(Class _ p) s@(Class _ q) =
    | t >: s = t
    | t <: s = s
    | p >: s = p
    | t <: q = q
    | otherwise = lub p q
lub Top _ = Top
lub _ Top = Top

Упражнение: покажите, что Typeобразует ограниченный полный набор в два пути, под <:и под >:.

Это потому, что операции независимы, поэтому связывание их вместе с отношениями подкласса на самом деле ничего не покупает. Скажем, вы хотели создать собственный тип, который реализован Bounded, возможно, Doublesограниченный между максимумом и минимумом, но вам не нужно было выполнять какие-либо Enumоперации. Если бы вы Boundedбыли подклассом, вам все Enumравно пришлось бы реализовать все функции, просто чтобы его скомпилировать.

На самом деле не имеет значения, есть ли разумная реализация Enumили любое другое количество классов типов. Если вам это на самом деле не нужно, вы не должны быть вынуждены это применять.

Сравните это с, скажем, Ordи Eq. Там Ordоперации зависят от Eqних, поэтому имеет смысл требовать подкласса, чтобы избежать дублирования и обеспечить согласованность.