Dlaczego Bounded nie jest podklasą Enum w Haskell

Wygląda na to, że każda instancja Bounded powinna mieć rozsądną implementację Enum. Nie mogę osobiście wymyślić kontrprzykładu, chociaż jeśli ktoś wymyśli taki, który nie jest patologiczny, zrozumiem, dlaczego tak nie jest.

Z robienia :ina dwóch typach klas wydaje się, że jedynym wyjątkiem obecnie w standardowej bibliotece są krotki, które są ograniczone, ale nie wyliczają. Jednak każda krotka Bounded musi być również wyliczalna w rozsądny sposób, po prostu zwiększając ostatni element, a następnie zawijając, gdy dojdzie do maxBound.

Ta zmiana prawdopodobnie wymagałaby również dodania predBi / nextBlub czegoś takiego do Bounded w celu bezpiecznego / zapętlonego sposobu przechodzenia przez wartości Enum. W takim przypadku toEnum 0 :: (...)byłoby równe(toEnum 0, toEnum 0, ...) :: (...)

Jeden praktyczny przykład, który mi się podoba, pochodzi ze świata języków programowania: zestaw typów w systemie OO jest ograniczony i dyskretny, ale nie można go wyliczyć i częściowo uporządkować, ale nie uporządkować całkowicie.

Przedmiotowe częściowe uporządkowanie jest relacją podtypu <:. Górna granica byłaby wówczas rodzajem górnym (które wywołuje C # objecti wywołania Scali Any), a dolna granica byłaby typem dolnym (Scala Nothing; C # / Java nie ma odpowiednika, o którym można mówić).

Jednak nie ma sposobu na wyliczenie wszystkich typów w systemie typów, więc nie można napisać an instance Enum Type. Powinno to być jasne: użytkownicy mogą pisać własne typy, więc nie ma sposobu, aby wiedzieć, co będą z góry. Możesz wyliczyć wszystkie typy w dowolnym programie, ale nie w całym systemie.

Podobnie (zgodnie z pewną rozsądną definicją podtypu) <:jest zwrotny, przechodni i antysymetryczny, ale nie całkowity . Istnieją pary typów, które nie są powiązane <:. ( Cati Dogoba są podtypami Animal, ale żaden z nich nie jest podtypem drugiego).

Załóżmy, że piszemy kompilator dla prostego języka OO. Oto reprezentacja typów w naszym systemie:

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

I definicja relacji podtypu:

(<:) :: 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

Daje nam to również relację nadrzędności.

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

Możesz także znaleźć najmniejszą górną granicę dwóch typów,

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

Ćwiczenie: pokaż, że Typetworzy pełny kompletny zbiór na dwa sposoby, pod <:i pod >:.

Wynika to z faktu, że operacje są niezależne, więc powiązanie ich z relacją podklasy tak naprawdę niczego nie kupi. Załóżmy, że chcesz utworzyć niestandardowy typ, który został zaimplementowany Bounded, być może Doublesograniczony między wartością maksymalną a minimalną, ale żadna z Enumoperacji nie była konieczna . Gdyby Boundedbyła podklasą, i tak musiałbyś zaimplementować wszystkie Enumfunkcje, żeby ją skompilować.

Tak naprawdę nie ma znaczenia, czy istnieje rozsądna implementacja Enumlub jakakolwiek inna liczba klas. Jeśli tak naprawdę go nie potrzebujesz, nie powinieneś być zmuszany do jego wdrożenia.

Porównaj to z powiedzmy Ordi Eq. Tam Ordoperacje są zależne od Eqtych, więc sensowne jest wymaganie podklasy, aby uniknąć powielania i zapewnić spójność.