Monad Transformers - Ben Kolera
Why Stack Overflow recommends it
Stack Overflow users link it when asking or answering how to structure large, modular Haskell applications with stacks of monad transformers.
Recommended by 2 people across 2 different months, 2010 to 2020.
What it is
A conference-style talk from the Brisbane Functional Programming Group in which Ben Kolera explains monad transformers and how to use them for configuration and error handling in Haskell code. It is a practical walkthrough aimed at people structuring real applications.
What people said
Strong rec liminalisht · 2016-04 · Stack Overflow · on “Large-scale design in Haskell?”
@Lii Ben Kolera [this video] gives a great practical intro to this topic, and Brian Hurt [LINK] discusses solutions to the problem of `lift`ing monadic actions into your custom monad. George Wilson [LINK] shows how to use `mtl` to write code that works with any monad that implements the required typeclasses, rather than your custom monad kind. Carlo Hamalainen [LINK] has written some short, useful notes summarizing George's talk.
Recommends Random dude · 2020-06 · Stack Overflow · on “How to manage internal state in a Haskell modular application?”
I am following the advise presented on this video by Ben Kolera [this video] for structuring modular Haskell applications. It is suggested to have multiple monad transformers to make the application modular and organized. Use of custom liftModule functions is suggested to compose these monads together. For example, we have a main App module and a Logic module. newtype App a = App { unApp :: ExceptT AppError (ReaderT AppEnv IO) a } newtype Logic a = Logic { unLogic :: ExceptT LogicError (Reader LogicEnv) a } liftLogic is defined as follows. runLogic :: LogicEnv -> Logic a -> Either LogicError a liftLogic :: Logic a -> App a liftLogic l = do c <- asks appEnvLogic either (throwError . AppLogicError)
Cites user349653 · 2010-06 · Stack Overflow · on “Large-scale design in Haskell?”
Don gave you most of the details above, but here's my two cents from doing really nitty-gritty stateful programs like system daemons in Haskell. In the end, you live in a monad transformer stack. At the bottom is IO. Above that, every major module (in the abstract sense, not the module-in-a-file sense) maps its necessary state into a layer in that stack. So if you have your database connection code hidden in a module, you write it all to be over a type MonadReader Connection m => ... -> m ... and then your database functions can always get their connection without functions from other modules having to be aware of its existence. You might end up with one layer carrying your database connecti