`StoreT` instances don't work well with other transformers

[jhbertra]

Problem

We're recently ran into an issue (which I believe @paluh discussed with you) regarding the instances for StoreT.

Our issue was that we wanted to add StoreT to our AppM transformer stack, which already had a ReaderT with an environment type. However, because StoreT already has a MonadAsk instance for the store type, we had to manually implement some instances to get the behaviour we desired.

You can see details here, along with our workaround:

marlowe-lang/marlowe-cardano#39

Summary of the changes I've made and would like to PR:

Add new instances for StoreT:

• MonadReader
• MonadTell
• MonadWriter
• MonadState
• MonadCont
• MonadRec
• MonadTrans
• Distributive

Modify MonadAsk instance for StoreT to delegate to the base monad m instead of the wrapped ReaderT (HalogenStore a s)

• MonadAsk - modified to delegate to base monad m with an instance of MonadAsk instead.

Add MonadStore instances for other monad transformers:

• ContT
• IdentityT
• MaybeT
• RWST
• ReaderT
• StateT
• WriterT

I can PR the necessary changes to fix this issue, and have already implemented them in our fork https://github.com/input-output-hk/purescript-halogen-store

I'm not able to open a PR on this repo however, I assume that it's restricted to contributors only?

While this is a breaking change I'm proposing, the migration steps are very straigtforward. It should be a simple matter of substituting usages of ask with getStore.

[jhbertra]

Some additional considerations:

If people are using combinators like asks, we could consider adding an equivalent getsStore which would allow a projection to be passed to the resulting store value, so that the translation is easier. Though this is arguably an antipattern, since in such cases, connect or emitSelected should probably be preferred for performance purposes

Furthermore, if people are using the MonadAsk instance in places where they want readonly access to the store, we could consider adding an intermediate typeclass for getStore, something like this:

class MonadEffect m <= MonadReadStore s m | m -> s where
  getStore :: m s
  emitSelected :: forall s'. Selector s s' -> m (Emitter s')

class MonadReadStore <= MonadStore a s m | m -> s a where
  updateStore :: a -> m Unit

[jhbertra]

Finally - thanks for creating this library. It is already helping us clean up our architecture quite a bit ❤️

[thomashoneyman]

Hi @jhbertra! Thanks for opening this issue, and I agree that this is an issue that I would like to see fixed. I've got a lot on my plate at the moment, so I apologize for the slow response; I haven't been able to thoroughly think through your comments and suggestions here just yet.

As far as this:

I'm not able to open a PR on this repo however, I assume that it's restricted to contributors only?

There are no restrictions on this repository, and others have opened PRs here (for example: #12); perhaps GitHub was just having an issue? I welcome PRs and am happy to review your changes!

[thomashoneyman]

Also, as you're looking at all of this, I'd recommend taking a peek at this branch:
https://github.com/thomashoneyman/purescript-halogen-store/tree/trh/run-store

...where I've pulled out the implementations into their own files for more flexibility -- so it's easier to define your own classes and helper functions on top of the existing implementations, rather than have to go through StoreT if you don't want to. I'm curious if you would benefit from that structure, or whether you don't see much advantage in it.