When is something an effect, and when is something a handle?

[ocharles]

I have a general question and I'm not sure it has an answer, but I thought it would be interesting to get a discussion going.

We generally have two options when we want to work with effects:

1. We add the effect to our monad itself. In effectful, this means defining an effect. Here the effect is threaded implicitly/automatically by GHC through type class constraints.
2. We can use the handle pattern.

For example, if I want to connect to a database I can either define an effect that gives me access to a database (e.g., Effectful.HPQTypes), or I can just thread around a handle to that connection (e.g., a postgresql-simple Connection).

Now this comparison might not be fair, because you might say that hpqtypes-effectful allows for re-interpretation of the effect. That's true, but we can also get that with the handle approach - we simply make our handle a record of effects.

The handle approach scales well when it comes to needing multiple instances of something. Having a single database connection requires the same type of code as multiple. However, in an effectful context dispatching queries to particular connections becomes much harder.

It can be sometimes hard to know when you'll only have a single instance or multiple, and in that sense the handle approach is quite nice and uniform.

To put this discussion in context, I'm exploring using effectful for a project at work. In this project I currently use the handle pattern, and I'm wondering whether or not I want to change that. I have some physical machinery that I can talk to to actuate motors or trigger cameras. The cameras in particular are problematic as we have multiple. The design I'm probably going to explore is having handles to various bits of machinery, but the actual acquisition or use of that handle requires access to a Hardware effect. In the database world, this would mean changing hpqtypes-effectful to be a combination of both a handle and an effect that lets you use the handle:

data Connection
withConnection :: DB :> es => ConnectInfo -> (Connection -> Eff es r) -> Eff es r
runQuery :: (DB :> es, IsSQL sql) => Connection -> sql -> Eff es Int

This is a bit rambly, and I don't quite know how to put into words what my actual question is - but I thought I'd just try and get some thoughts out! CC @tomjaguarpaw, as I know you're very interested in a more explicit encoding of effect handles.

[arybczak]

For the record, I already expressed on reddit and discourse why I think passing effects explicitly is much less ergonomic than having them as constraints.

However, I realize that there might be a need of having multiple instances of a specific effect in scope at the same time. So I experimented a bit and came up with #138.

Let me know what you think about this.

[arybczak]

It's a version of Tagged for effects.

Newtyping is a bit different, I think a generic adapter for newtyped effects can also be written.

[arybczak]

@tomjaguarpaw For the record, I think writing an adapter that transforms any effect into a regular argument that can be explicitly passed is also possible. I'll have a look at it later.

[ocharles]

Do you see problems with the current approach that effectful would solve?

I'm interested in switching out of the handle approach because my handles are records of IO calls, so doing anything with a handle incurs a MonadIO constraint. It'd be nice to be a bit more fine-grained here - and there are a few ways to do that.

[arybczak]

Makes sense 🙂

Btw, I was wondering that perhaps thinking about labeling effects or passing them explicitly is just considering a suboptimal design (not that it's not useful in a pinch, but ideally speaking)?

Because this is generally what happens with these primitive effects like State and Reader - you create more specialized effects that use these effects internally and then you don't care that two of your effects use e.g. a State (IntMap String), because they are only visible to the effect handler.

I'm not sure if this makes sense, just something I thought of.

[ocharles]

I guess you mean use a more domain-specific effect that has an interpretation that uses State or Reader? If so I somewhat agree - but it does increase the general complexity or overhead imo. It's somewhat akin to what the OO world do creating interfaces for the purposes of dependency inversion, I think. Generally when something only has one implementation, I prefer to just use that, rather than the abstraction - but I'm not sure how well that philosophy gels with effect systems.