Providing a "view" over mutable state

[sirrus233]

New to effectful and having a pretty fun time so far! But struggling a bit with the mental model.

I have a pattern I'm trying to implement where I have some mutable state in my effects (say, with the State effect), but with the ability to constrain my effects down to just a view of this state, where it can be read but not modified.

In mtl world, I think this is relatively straightforward. If I have:
newtype MyMonadStack = MyMonadStack (StateT MyState IO a)
then I can have a MonadReader instance and constrain a function like
f :: (MonadReader MyState m) => a -> m b or g :: a -> MyMonadStack b
and then f can operate within g to clearly signal the intent that it's a read-only access of the state.

With effectful, I'm not sure how to achieve the equivalent. I tried defining a custom View effect with a runView that depends on a State :> es constraint -- and that actually seemed to carry me a little ways, until I tried to define a MonadReader instance for View (which would be nice to have for lenses or other library interop). I ran into trouble there because MonadReader also needed to carry the State :> es constraint (of course), but at that point it became impossible for a function to satisfy the MonadReader constraint without ALSO satisfying the State constraint, and that defeated the entire purpose of preventing mutation in a read-only context.

Is there a better way to go about this?

It's possible I'm thinking about this in a weird way or missing something obvious, so please also feel free to tell me if this is not a well-formed question :)

[arybczak]

If you do

import Effectful
import Effectful.Dispatch.Dynamic
import Effectful.State.Static.Local

data View v :: Effect where
  View :: View v m v
type instance DispatchOf (View v) = Dynamic

viewState :: State s :> es => Eff (View s : es) a -> Eff es a
viewState = interpret_ $ \View -> get

then you can use View directly (as you said). Defining a MonadReader instance is possible with

instance (View v :> es, MonadReader v (Eff es)) => MonadReader v (Eff es) where
  ask = send View

Note that it doesn't mention State. But it's a bad idea, since

1. It's the only instance of MonadReader for (Eff es) that can be defined.
2. It doesn't work very well with MonadReader's fundeps (hence the hack of putting the instance head in the context).

See https://hackage.haskell.org/package/effectful-core-2.5.1.0/docs/Effectful-Dispatch-Dynamic.html#g:4 for more info.

[sirrus233]

That does exactly what I was trying to do. Thank you!

I see that you wrote this as a dynamically dispatched effect. Just for my own understanding/learning - is it possible to write a statically dispatched version? And if so, what does that look like? I'm still trying to wrap my head around the difference, but I suppose I thought that if Reader and State can be implemented as static effects, that would make sense for this View effect as well.

But it's a bad idea

What is? Defining a MonadReader? I did read the documentation, but I'm not sure I understand. Can you elaborate more here?

It's the only instance of MonadReader for (Eff es) that can be defined.

Ah, do you mean that if we had some other effect that needed to implement MonadReader, we couldn't do both that and this?

If this is a bad idea - is there a "good" way to go about what I'm trying to do? Or would you consider it a fundamentally a bad abstraction?

[arybczak]

Here's actually a better solution:

import Effectful
import Effectful.Dispatch.Dynamic
import Effectful.State.Static.Local qualified as S

data Get v :: Effect where
  Get :: Get v m v
type instance DispatchOf (Get v) = Dynamic

data Put v :: Effect where
  Put :: v -> Put v m ()
type instance DispatchOf (Put v) = Dynamic

runGetPut :: forall v es a. v -> Eff (Get v : Put v : es) a -> Eff es (a, v)
runGetPut v0 = S.runState v0 . interpret_ (\(Put v) -> S.put v) . interpret_ (\Get -> S.get) . hideState
  where
    hideState :: Eff (Get v : Put v : es) a -> Eff (Get v : Put v : S.State v : es) a
    hideState = inject

It splits State into two effects and hides the original. So now your functions that modify the state will include both Get and Put, while the ones that read only Get.

If this is a bad idea - is there a "good" way to go about what I'm trying to do?

I don't understand why you want to define a MonadReader instance in the first place. Doesn't the above code solve your problem?

If you're writing an application and want integration with the code that uses MonadReader, feel free to use the instance I wrote above. But MonadReader also wants you to define local (which is kinda like modify), how do you want to work around this?

[sirrus233]

It certainly solves the problem of providing a read-only view over a State effect. But suppose I want to interop with a library that expects a MonadReader or MonadState instance (say lens, or optics, in my case). Then my understanding is that I would either need to provide these instances, or else basically write a whole compatibility layer for the libraries API. Is that not correct?

[arybczak]

Yeah, pretty much. There's a PR for effectful-optics that's been stale, but I don't think that would help you since you have your own effects instead of Reader/State.

But if you're writing an application, feel free to write these instances yourself.

[sirrus233]

I gotcha. Thanks for the help!

[arybczak]

This got me thinking that perhaps it would be a good idea to make effectful provide MonadReader, MonadWriter and MonadState instances for Eff via dynamic Reader/Writer/State effects for compatibility with existing utility libraries. Thoughts?