Чому не обмежений підклас Енума в Хаскеллі

Схоже, що будь-який обмежений екземпляр повинен мати розумну реалізацію Enum. Я особисто не можу придумати контрприклад, хоча якщо хтось придумає той, який не є патологічним, то я зрозумію, чому це не так.

З того, що робити :iна двох класах типових класів, здається, єдиним винятком, який зараз є у стандартній бібліотеці, є кортежі, які є Bounded, але не Enums. Однак будь-який обмежений кортеж також повинен бути численним у розумному вигляді, просто збільшуючи останній елемент, а потім обертаючись, коли він дістається до maxBound.

Ця зміна, ймовірно, також передбачає додавання predBта nextBчимось подібне до Обмеженого для безпечного / циклічного способу проходу через значення Enum. У цьому випадку toEnum 0 :: (...)було б дорівнює(toEnum 0, toEnum 0, ...) :: (...)

Один практичний приклад, який мені подобається, походить із світу мов програмування: набір типів в системі ОО обмежений і дискретний, але не перелічений, частково впорядкований, але не повністю упорядкований.

Про часткове впорядкування, про яке йде мова, є відношення підтипу <:. Верхня межа буде тоді верхнім типом (який викликає C # objectта Scala Any), а нижньою є нижня ( типом Scala Nothing; C # / Java не може бути еквівалентним).

Однак немає можливості перерахувати всі типи в системі типів, тому ви не можете написати an instance Enum Type. Це повинно бути зрозуміло: користувачі можуть писати власні типи, тому немає можливості знати заздалегідь. Ви можете перерахувати всі типи в будь-якій заданій програмі, але не у всій системі.

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

Припустимо, ми пишемо компілятор для простої мови ОО. Ось представлення типів у нашій системі:

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, тому має сенс вимагати від підкласу, щоб уникнути дублювання та забезпечити узгодженість.