Por que Bounded não é uma subclasse de Enum em Haskell

Parece que qualquer instância vinculada deve ter uma implementação sã do Enum. Pessoalmente, não consigo pensar em um contra-exemplo, embora, se alguém criar um que não seja patológico, entenderei por que não é esse o caso.

Ao executar :inas duas classes de tipos, parece que a única exceção atualmente na biblioteca padrão é para tuplas, que são limitadas, mas não enums. No entanto, qualquer tupla limitada também deve ser enumerável de maneira sã, simplesmente incrementando o último elemento e, em seguida, contornando quando se trata de maxBound.

Essa alteração provavelmente envolveria também a adição predBe / nextBou algo parecido a Bounded, para uma maneira segura / em loop de percorrer os valores de Enum. Nesse caso, toEnum 0 :: (...)seria igual a(toEnum 0, toEnum 0, ...) :: (...)

Um exemplo prático que eu gosto vem do mundo das linguagens de programação: o conjunto de tipos em um sistema OO é limitado e discreto, mas não enumerável, e parcialmente ordenado, mas não totalmente ordenado.

A ordem parcial em questão é a relação de subtipagem <:. O limite superior seria então o tipo superior (que C # chama objecte Scala chama Any), e o limite inferior seria o tipo inferior (Scala Nothing; C # / Java não tem equivalente para falar).

No entanto, não há como enumerar todos os tipos no sistema de tipos, portanto você não pode escrever um instance Enum Type. Isso deve ficar claro: os usuários podem escrever seus próprios tipos, para que não haja como saber com antecedência. Você pode enumerar todos os tipos em qualquer programa, mas não em todo o sistema.

Da mesma forma, (de acordo com uma certa definição razoável de subtipagem), <:é reflexivo, transitivo e anti-simétrico, mas não total . Existem pares de tipos que não são relacionados <:. ( Cate Dogsão ambos subtipos de Animal, mas nenhum é um subtipo do outro.)

Suponha que estamos escrevendo um compilador para uma linguagem OO simples. Aqui está a representação dos tipos em nosso sistema:

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

E a definição da relação de subtipagem:

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

Isso também nos dá uma relação de super tipagem.

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

Você também pode encontrar o limite superior mínimo de dois tipos,

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

Exercício: mostre que Typeforma um poset completo delimitado de duas maneiras, abaixo <:e abaixo >:.

É porque as operações são independentes, portanto, vinculá-las a um relacionamento de subclasse não compram nada para você. Digamos que você desejasse criar um tipo personalizado implementado Bounded, talvez Doublesrestrito entre um máximo e um mínimo, mas você não precisou de nenhuma das Enumoperações. Se Boundedfosse uma subclasse, você teria que implementar todas as Enumfunções de qualquer maneira, apenas para compilar.

Realmente não importa se existe uma implementação razoável para Enum, ou qualquer outro número de classes de tipo. Se você realmente não precisa, não deve ser forçado a implementá-lo.

Compare isso com dizer, Orde Eq. Lá, as Ordoperações dependem Eqdelas, portanto, faz sentido exigir que a subclasse evite duplicação e garanta consistência.