2014-09-13 8 views

risposta

14

C'è un cambiamento funzionale. ErrorT richiede che il tipo e sia un membro di Error type class -for esempio, considerare i suoi vincoli di istanza Monad. Questo è abbastanza arbitrario e certamente non necessario per la funzionalità di ErrorT.

ExceptT solleva questa restrizione.

La ridenominazione è stata introdotta per creare un percorso di aggiornamento più fluido. Le persone che attualmente utilizzano e dipendono dal vincolo Error nei loro stack ErrorT non devono modificare il codice. Le persone che desiderano utilizzare il modulo più rigoroso ExceptT possono liberamente scegliere di farlo. Ad un certo punto il modulo ErrorT può essere rimosso.

3

C'è un cambiamento nella semantica.

ErrorT e m aspetta che e implementa la classe Error nella sua Monad esempio. Questo permette l'implementazione di fail per ErrorT e m un'eccezione:

fail msg = ErrorT $ return (Left (strMsg msg)) 

Al contrario, ExceptT non ha alcun tale restrizione. Invece l'attuazione di fail per ExceptT e m chiama l'eccezione nella monade sottostante m:

fail = ExceptT . fail 

preferisco comportamento ErrorT s' in quanto mi permette di catturare qualsiasi istanza in cui fail è chiamato dal codice sopra una monade generico. In ogni caso, è importante rivedere il codice prima di annullare la ridenominazione dello ErrorT allo ExceptT.

+0

Se non riesci a "fallire", non troverai questa difficoltà. – dfeuer

+0

Questo semplicemente non è vero. GHC richiama implicitamente anche fail quando mai una corrispondenza di modello fallisce: –

+0

Come nota a margine, scrivo un sacco di codice Haskell, e tendo spesso a usare typechecker per catturare errori. Nel bene o nel male, il fallimento fa parte di Monad. Penso che sia terribile per un manutentore della libreria emettere avvisi di deprecazione che raccomandano modifiche che interromperanno silenziosamente il codice dell'applicazione perché hanno cambiato la semantica di un'operazione in modo sottile e scarsamente documentato. –