Perché non è associato una sottoclasse di Enum in Haskell

Sembra che ogni istanza rilegata dovrebbe avere un'implementazione sana di Enum. Non riesco a pensare personalmente a un controesempio, anche se se qualcuno ne trova uno che non è patologico, capirò perché non è così.

Dal fare :isui due caratteri tipografici sembra che l'unica eccezione attualmente nella libreria standard sia per le tuple, che sono limitate ma non Enum. Tuttavia, qualsiasi tupla legata deve anche essere enumerabile in modo sano, semplicemente incrementando l'ultimo elemento e poi avvolgendosi quando arriva a maxBound.

Questo cambiamento sarebbe probabilmente coinvolgere anche aggiungere predBe nextBo qualcosa di simile ad Delimitata per una cassetta di sicurezza / loop modo di attraversare attraverso i valori Enum. In questo caso toEnum 0 :: (...)sarebbe uguale a(toEnum 0, toEnum 0, ...) :: (...)

Un esempio pratico che mi piace viene dal mondo dei linguaggi di programmazione: l'insieme di tipi in un sistema OO è limitato e discreto ma non enumerabile, e parzialmente ordinato ma non completamente ordinato.

L'ordinamento parziale in questione è la relazione di sottotipizzazione <:. Il limite superiore sarebbe quindi il tipo superiore (che chiama C # objecte Scala chiama Any) e il limite inferiore sarebbe il tipo inferiore (Scala's Nothing; C # / Java non hanno equivalenti di cui parlare).

Tuttavia, non è possibile enumerare tutti i tipi nel sistema dei tipi, quindi non è possibile scrivere un instance Enum Type. Questo dovrebbe essere chiaro: gli utenti possono scrivere i propri tipi, quindi non c'è modo di sapere cosa saranno in anticipo. Puoi enumerare tutti i tipi in qualsiasi programma, ma non nell'intero sistema.

Allo stesso modo, (secondo una certa ragionevole definizione di sottotipizzazione) <:è riflessivo, transitivo e antisimmetrico ma non totale . Esistono coppie di tipi non correlate da <:. ( Cate Dogsono entrambi sottotipi di Animal, ma nessuno dei due è un sottotipo dell'altro.)

Supponiamo di scrivere un compilatore per un semplice linguaggio OO. Ecco la rappresentazione dei tipi nel nostro sistema:

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

E la definizione della relazione di sottotipo:

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

Questo ci dà anche una relazione supertipica.

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

Puoi anche trovare il limite superiore minimo di due tipi,

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

Esercizio: mostra che Typeforma un poset completo limitato in due modi, sotto <:e sotto >:.

È perché le operazioni sono indipendenti, quindi collegarle con una relazione di sottoclasse non ti compra nulla. Supponiamo che tu voglia creare un tipo personalizzato implementato Bounded, magari Doublesvincolato tra un massimo e un minimo, ma non hai bisogno di nessuna delle Enumoperazioni. Se Boundedfosse una sottoclasse, dovresti Enumcomunque implementare tutte le funzioni, solo per farlo compilare.

Non importa se esiste un'implementazione ragionevole per Enum, o qualsiasi altro numero di macchine da scrivere. Se in realtà non ne hai bisogno, non dovresti essere costretto a implementarlo.

Contrastare questo con dire, Orde Eq. Lì, le Ordoperazioni dipendono da Eqquelle, quindi ha senso richiedere la sottoclasse per evitare duplicazioni e garantire coerenza.