MonadSTM

[mitchellwrosen]

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 ()

[simonmar]

Seems reasonable. Want to make a PR?

[mitchellwrosen]

Sure

[seanhess]

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

[mitchellwrosen]

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

[demming]

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

[fumieval]

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