¿Por qué Bounded no es una subclase de Enum en Haskell?

Parece que cualquier instancia de Bounded debería tener una implementación sensata de Enum. No puedo pensar personalmente en un contraejemplo, aunque si a alguien se le ocurre uno que no sea patológico, entenderé por qué este no es el caso.

Al hacerlo :ien las dos clases de tipos, parece que la única excepción actualmente en la biblioteca estándar es para las tuplas, que son limitadas pero no enumeraciones. Sin embargo, cualquier tupla limitada también debe ser enumerable de una manera sensata, simplemente incrementando el último elemento y luego envolviéndolo cuando llegue a maxBound.

Este cambio probablemente también implicaría agregar predBy / nextBo algo así a Bounded para una forma segura / en bucle para atravesar los valores de Enum. En este caso toEnum 0 :: (...)sería igual a(toEnum 0, toEnum 0, ...) :: (...)

Un ejemplo práctico que me gusta proviene del mundo de los lenguajes de programación: el conjunto de tipos en un sistema OO es limitado y discreto pero no enumerable, y está parcialmente ordenado pero no totalmente ordenado.

El ordenamiento parcial en cuestión es la relación de subtipo <:. El límite superior sería el tipo superior (que C # llama objecty llama a Scala Any), y el límite inferior sería el tipo inferior (Scala Nothing; C # / Java no tienen equivalente para hablar).

Sin embargo, no hay forma de enumerar todos los tipos en el sistema de tipos, por lo que no puede escribir un instance Enum Type. Esto debería estar claro: los usuarios pueden escribir sus propios tipos, por lo que no hay forma de saber de antemano qué serán. Puede enumerar todos los tipos en cualquier programa dado, pero no en todo el sistema.

Del mismo modo, (de acuerdo con una cierta definición razonable de subtipo), <:es reflexivo, transitivo y antisimétrico, pero no total . Hay pares de tipos que no están relacionados por <:. ( Caty Dogambos son subtipos de Animal, pero ninguno es subtipo del otro).

Supongamos que estamos escribiendo un compilador para un lenguaje OO simple. Aquí está la representación de tipos en nuestro sistema:

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

Y la definición de la relación de subtipo:

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

Esto también nos da una relación de supertipaje.

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

También puede encontrar el límite superior mínimo de dos 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

Ejercicio: muestra que Typeforma un poset completo acotado de dos maneras, debajo <:y debajo >:.

Es porque las operaciones son independientes, por lo que vincularlas con una relación de subclase en realidad no te compra nada. Supongamos que desea crear un tipo personalizado que se implemente Bounded, tal vez Doubleslimitado entre un máximo y un mínimo, pero no tuvo necesidad de ninguna de las Enumoperaciones. Si Boundedfuera una subclase, tendría que implementar todas las Enumfunciones de todos modos, solo para que se compile.

Realmente no importa si hay una implementación razonable Enumo cualquier otro número de clases de tipos. Si realmente no lo necesita, no debería verse obligado a implementarlo.

Contraste esto con decir, Ordy Eq. Allí, las Ordoperaciones dependen de las Eqmismas, por lo que tiene sentido exigir a la subclase para evitar la duplicación y garantizar la coherencia.