Scrivere un Monad Transformer, ha davvero bisogno di così tante istanze hardcoded

Question

Sono un utente di trasformatore monade da molto tempo, scrittore di trasformatori monade prima volta ... E mi sento come se avessi fatto qualcosa di non necessario.

Stiamo lavorando su un progetto che ha più tabelle DB, e l'hardcoding del set in diversi stack monad stava diventando poco maneggevole, così abbiamo deciso di suddividerlo in diversi trasformatori monad innestabili, permettendoci di scegliere il tipo di funzione livello, come questo

doSomething::(HasUserTable m, HasProductTable m)=>Int->m String 

(HasXTable è la classe, xTablet è il trasformatore monade calcestruzzo). Questi separatori separati possono essere inseriti o rimossi in modo completamente modulare e memorizzeranno gli handle DB, richiedono ResourceT, ecc ....

Il mio primo tentativo è stato quello di racchiudere ReaderT, che sarebbe stato utilizzato per tenere l'handle del DB. Divenne immediatamente evidente che ciò non avrebbe funzionato, in quanto ReaderT (e StateT, ecc.) Non possono essere impilati senza usare catene di "lift" hardcoded, rompendo così la modularità collegabile degli elementi stack.

L'unica soluzione sembrava essere quella di scrivere copie completamente separate della monade ReaderT, ognuna delle quali consentiva l'accesso agli altri ad un livello inferiore. Questo funziona, ma la soluzione è pieno di codice standard, qualcosa di simile

class HasUserTable m where 
    getUser::String->m User 

newtype UserTableT m r = UserTableT{runUserTableT::String->m r} 

--Standard monad instance stuff, biolerplate copy of ReaderT 
instance Functor m=>Functor (UserTableT m) where.... 
instance Applicative m=>Applicative (UserTableT m) where.... 
instance Monad m=>Monad (UserTableT m) where.... 
instance Monad m=>HasUserTable (UserTableT m) where.... 

--Gotta hardcode passthrough rules to every other monad transformer 
--in the world, mostly using "lift".... 
instance MonadTrans BlockCacheT where.... 
instance (HasUserTable m, Monad m)=>HasUserTable (StateT a m).... 
instance (HasUserTable m, Monad m)=>HasUserTable (ResourceT m).... 
.... etc for all other monad transformers 

--Similarly, need to hardcode passthrough rules for all other monads 
--through the newly created one 
instance MonadResource m=>MonadResource (UserTableT m) where.... 
instance MonadState a m=>MonadState a (UserTableT m) where.... 
instance (MonadBaseControl IO m) => MonadBaseControl IO (UserTableT m).... 
.... etc for all other monad transformers 

Ciò che rende questo ancora peggiore è che abbiamo bisogno di aggiungere regole ancora più passthrough per ogni nuovo trasformatore monade aggiungiamo (IE- ogni nuova tabella aggiungiamo necessità di passare attraverso tutti gli altri trasformatori di tabella, quindi abbiamo bisogno di n^2 dichiarazioni di istanza!)

C'è un modo più pulito per fare questo?

Answer 1

Sì, questo è uno dei problemi con i trasformatori monod: quando aggiungi un nuovo trasformatore, devi scrivere un numero sempre crescente di istanze di piastre. Sono le istanze n ogni volta, per un totale di O (n^2) istanze. Ad esempio, è possibile osservare questo problema di ridimensionamento in the mtl source code. I trasformatori Monad non sono facilmente estensibili.

Ora, una buona percentuale delle monadi che usiamo quotidianamente può essere espressa come una combinazione dei trasformatori forniti da mtl, il che significa che qualcun altro ha già fatto il lavoro di scrivere tutte quelle noiose istanze. Ma questi trasformatori non coprono certamente lo ogni monade e ti mordere ogni volta che devi scriverlo da solo.

Ecco perché è in corso uno sforzo per elaborare nuovi approcci per effettuare la digitazione. Un buon esempio in Haskell è Kiselyov et al's extensible-effects library, che adotta un approccio algebrico per effettuare la digitazione, basato sulle monadi gratuite. Il design di questa libreria è descritto in due articoli: An Alternative to Monad Transformers, che impiega un po 'di tempo a descrivere problemi con l'approccio mtl e More Extensible Effects, descrivendo un'implementazione aggiornata e ottimizzata della libreria.

Se si desidera vedere fino a che punto è possibile eseguire la digitazione dell'effetto sicuro ed estendibile, vedere effects library di Edwin Brady per il linguaggio Idris. Esistono molte risorse che spiegano effects: un tutorial, l'articolo originale Programming and Reasoning with Algebraic Effects e Resource-dependent Algebraic Effects che descrive alcune funzionalità più recenti di effects. Probabilmente ci sono altre risorse che ho dimenticato in questa lista.