stm MonadSTM

Could this MonadSTM type class be adopted by the stm package?

It would be useful for certain abstractions such as the "console region" defined in concurrent-output, which currently defines its own equivalent type class.

My use case involves a monad transformer atop such a thing; I want to write a type signature like:

(MonadReader Env m, MonadSTM m) => m ()

Jun 14 '19 17:06 mitchellwrosen

Seems reasonable. Want to make a PR?

Jun 17 '19 07:06 simonmar

Sure

Jun 17 '19 16:06 mitchellwrosen

Is there any movement on this? Or is there another recommended path? It seems like wanting to have your TVars in a MonadReader instance would be a pretty common use case

Nov 10 '20 19:11 seanhess

As far as I can tell the PR is ready to merge

Nov 13 '20 17:11 mitchellwrosen

Hey, any updates on this issue? I too would love to use it from the stm package.

Mar 24 '21 22:03 demming

I'm not sure if it's a good idea to provide instances for both STM and IO. Unlike MonadIO, it's not a monad homomorphism because liftRegion (a >>= k) and liftRegion m >>= liftRegion . k are completely different; hiding atomically semantics behind such abstraction seems like a footgun.

If the usecase is about monads like ReaderT Env STM, it should not have an instance for IO. Otherwise generalising atomically to MonadIO m => STM a -> m a seem like the right approach

Jan 10 '22 05:01 fumieval