Le monadi sono un'alternativa praticabile (forse preferibile) alle gerarchie ereditarie?

Userò una descrizione indipendente dal linguaggio di monadi come questa, descrivendo prima i monoidi:

Un monoide è (approssimativamente) un insieme di funzioni che accettano un tipo come parametro e restituiscono lo stesso tipo.

Una monade è (approssimativamente) un insieme di funzioni che accettano un tipo di wrapper come parametro e restituiscono lo stesso tipo di wrapper.

Nota che sono descrizioni, non definizioni. Sentiti libero di attaccare quella descrizione!

Quindi in un linguaggio OO, una monade consente composizioni operative come:

Flier<Duck> m = new Flier<Duck>(duck).takeOff().flyAround().land()

Si noti che la monade definisce e controlla la semantica di tali operazioni, piuttosto che la classe contenuta.

Tradizionalmente, in un linguaggio OO useremmo una gerarchia di classi ed ereditarietà per fornire quella semantica. Così avremmo una Birdclasse con metodi takeOff(), flyAround()e land(), e anatra avrebbero ereditato quelli.

Ma poi ci mettiamo nei guai con gli uccelli incapaci di volare, perché penguin.takeOff()falliscono. Dobbiamo ricorrere al lancio e alla gestione delle eccezioni.

Inoltre, una volta che diciamo che Penguin è un Bird, ci imbattiamo in problemi con eredità multipla, ad esempio se abbiamo anche una gerarchia di Swimmer.

In sostanza stiamo provando a mettere le classi in categorie (con scuse per i ragazzi della teoria delle categorie) e definire la semantica per categoria piuttosto che nelle singole classi. Ma le monadi sembrano un meccanismo molto più chiaro per farlo rispetto alle gerarchie.

Quindi, in questo caso, avremmo una Flier<T>monade come nell'esempio sopra:

Flier<Duck> m = new Flier<Duck>(duck).takeOff().flyAround().land()

... e non avremmo mai un'istanza a Flier<Penguin>. Potremmo anche usare la tipizzazione statica per evitare che ciò accada, magari con un'interfaccia marcatore. O il controllo delle capacità di runtime per il salvataggio. Ma davvero, un programmatore non dovrebbe mai mettere un Pinguino in Flier, nello stesso senso in cui non dovrebbe mai dividere per zero.

Inoltre, è più generalmente applicabile. Un volantino non deve essere un uccello. Ad esempio Flier<Pterodactyl>, oppure Flier<Squirrel>, senza modificare la semantica di quei singoli tipi.

Una volta classificata la semantica in base a funzioni componibili su un contenitore - anziché con gerarchie di tipi - risolve i vecchi problemi con le classi che "tipo di fare, tipo di non" rientrano in una particolare gerarchia. Inoltre, consente facilmente e chiaramente più semantiche per una classe, come Flier<Duck>pure Swimmer<Duck>. Sembra che abbiamo lottato con una discrepanza di impedenza classificando il comportamento con le gerarchie di classi. Le monadi lo gestiscono elegantemente.

Quindi la mia domanda è, allo stesso modo in cui siamo arrivati ​​a favorire la composizione sull'eredità, ha senso anche favorire le monadi sull'eredità?

(A proposito non ero sicuro se questo dovesse essere qui o in Comp Sci, ma questo sembra più un problema pratico di modellazione. Ma forse è meglio laggiù.)

La risposta breve è no , le monadi non sono un'alternativa alle gerarchie ereditarie (noto anche come polimorfismo dei sottotipi). Sembra che tu stia descrivendo il polimorfismo parametrico , di cui le monadi si avvalgono ma non sono l'unica cosa per farlo.

Per quanto li capisco, le monadi non hanno essenzialmente nulla a che fare con l'eredità. Direi che le due cose sono più o meno ortogonali: hanno lo scopo di affrontare diversi problemi, e quindi:

1. Possono essere usati sinergicamente in almeno due sensi:
   • controlla la Typeclassopedia , che copre molte delle classi di tipi di Haskell. Noterai che ci sono relazioni simili all'eredità tra di loro. Ad esempio, Monade è discendente da Applicativo che è esso stesso discendente da Functor.
   • i tipi di dati che sono istanze di Monadi possono partecipare alle gerarchie di classi. Ricorda, Monad è più simile a un'interfaccia: implementarla per un determinato tipo ti dice alcune cose sul tipo di dati, ma non tutto.
2. Cercare di usare l'uno per fare l'altro sarà difficile e brutto.

Infine, sebbene ciò sia tangenziale alla tua domanda, potresti essere interessato a sapere che le monadi hanno dei modi incredibilmente potenti per comporre; leggi sui trasformatori di monade per saperne di più. Tuttavia, questa è ancora un'area attiva di ricerca perché noi (e per noi, intendo le persone 100000 volte più intelligenti di me) non abbiamo trovato ottimi modi per comporre le monadi, e sembra che alcune monadi non compongano arbitrariamente.

Ora, per scegliere la tua domanda (scusami, intendo che ciò sia utile e non ti faccia stare male): Sento che ci sono molte premesse discutibili su cui cercherò di far luce.

1. Una monade è un insieme di funzioni che accettano un tipo di contenitore come parametro e restituiscono lo stesso tipo di contenitore.

   No, questo è Monadin Haskell: un tipo m acon parametri con un'implementazione di return :: a -> m ae (>>=) :: m a -> (a -> m b) -> m b, che soddisfa le seguenti leggi:

   return a >>= k  ==  k a
   m >>= return  ==  m
   m >>= (\x -> k x >>= h)  ==  (m >>= k) >>= h
   

   Ci sono alcune istanze di Monad che non sono container ( (->) b) e ci sono alcuni contenitori che non sono (e non possono essere create) istanze di Monad ( Set, a causa del vincolo di classe del tipo). Quindi l'intuizione "contenitore" è scarsa. Vedi questo per altri esempi.

2. Quindi in un linguaggio OO, una monade consente composizioni operative come:

     Flier<Duck> m = new Flier<Duck>(duck).takeOff().flyAround().land()
   

   No, per niente. Quell'esempio non richiede una Monade. Tutto ciò che serve sono funzioni con tipi di input e output corrispondenti. Ecco un altro modo di scriverlo che sottolinea che si tratta solo di un'applicazione di funzioni:

   Flier<Duck> m = land(flyAround(takeOff(new Flier<Duck>(duck))));
   

   Credo che questo sia uno schema noto come "interfaccia fluente" o "concatenamento di metodi" (ma non ne sono sicuro).

3. Si noti che la monade definisce e controlla la semantica di tali operazioni, piuttosto che la classe contenuta.

   I tipi di dati che sono anche monadi possono (e quasi sempre lo fanno!) Avere operazioni non correlate alle monadi. Ecco un esempio di Haskell composto da tre funzioni sulle []quali non ha nulla a che fare con le monadi: []"definisce e controlla la semantica dell'operazione" e la "classe contenuta" no, ma non è sufficiente per creare una monade:

   \predicate -> length . filter predicate . reverse
   

4. Hai notato correttamente che ci sono problemi con l'uso delle gerarchie di classi per modellare le cose. Tuttavia, i tuoi esempi non presentano alcuna prova che le monadi possano:

   • Fai un buon lavoro in quelle cose in cui l'eredità è brava
   • Fai un buon lavoro in quella roba in cui l'eredità è cattiva

Quindi la mia domanda è, allo stesso modo in cui siamo arrivati ​​a favorire la composizione sull'eredità, ha senso anche favorire le monadi sull'eredità?

In lingue non OO, sì. Nelle lingue OO più tradizionali, direi di no.

Il problema è che la maggior parte delle lingue non ha specializzazione di tipo, il che significa che non è possibile effettuare Flier<Squirrel>e Flier<Bird>avere implementazioni diverse. Devi fare qualcosa di simile static Flier Flier::Create(Squirrel)(e quindi sovraccaricare per ogni tipo). Il che a sua volta significa che devi modificare questo tipo ogni volta che aggiungi un nuovo animale e probabilmente duplicare un bel po 'di codice per farlo funzionare.

Oh, e in non poche lingue (ad esempio C #) public class Flier<T> : T {}è illegale. Non costruirà nemmeno. La maggior parte, se non tutti i programmatori OO, si aspetterebbero Flier<Bird>di essere ancora un Bird.