Monad Transformer State
summary
Claim: lifting control-style IO functions over transformers that carry mutable monadic state can silently discard updates. Demonstrations use lifted-async and monad-control: concurrently run on StateT consistently yields the second thread’s state (concurrently returns second thread's state, always 4), and bracket semantics differ by library (bracket semantics differ between libraries). Workarounds: restrict app monad to ReaderT/RIO and use real mutable cells (IORef/STM) instead of StateT for shared/updatable state, or use unliftio for safe unlifting where it’s supported.
AI-written summary · about
chapters (14)
- 0:00Intro
- 0:50What's a monad transformer?
- 1:29Which transformers are we covering?
- 2:27Meet the transformers
- 3:09A concurrent problem
- 6:52Ask, lift, and run • Don't need to use explicit data constructor unwrapping
- 8:35Pop quiz! What is the output of this program
- 14:01Take a step back 1. This is not just a bug in implementation 2. The ambiguity and discarding is inherent to implementing the algorithm 3. We cannot implement some classes of functions for
- 15:25But does it lift? Which of these functions can be converted to stater
- 16:47Monad transformer environment versus state
- 21:14Natural linear call path Even though catch has two input actions, the handler is only called after the main action completes
- 23:23The problem cases Two categories of problem cases 1. Things like finally: can manually reimplement
- 23:52Cheating
- 29:16Use mutable variables
related talks
01h 07mMonad transformers are good, actually
24mUsing Monad Transformers without understanding them
47mMonad transformers down to earth
44mIO monad & Error management: From Exceptions to Cats MTL
42mMonads you already use without knowing it
39mShared State In Pure Fp When A State Monad Won't Do
38mA roadtrip with monads: from MTL, through tagless, to BIO
26mUP YOUR MTL GAME WITH CLASSY OPTICS