Open tomjaguarpaw opened 6 months ago
By the way, this was prompted by the talk Wire all the things! by Eric Torreborre (Lambda Days 2023) where he says of effect systems
You have to introduce a separation, you cannot use functions directly any more, you have to use data types that are representing your functions. And at large, that makes the code a bit hard to navigate.
I guessed that wasn't true, and lo and behold, after some work, it isn't!
Does this work for higher order effects? EffectDirect looks annoying to write and it looks like it won't be enough for higher order, i.e. you would also need the reverse mapping
I doubt it works for higher order effects. But I'm also confused about what higher order effects are. As far as I can tell, they're just handlers. So perhaps dynamic higher order effects are dynamic handers? I've never wanted one of those. I wonder what they are for.
I doubt it works for higher order effects.
Actually, I take that back. Since a higher order effect is still just a function defined in terms of the current effect set, the direct encoding should be able to do that too. I still don't understand what higher order effects are for (versus just handlers) though.
data Foo :: Effect where
Foo :: m a -> Foo m a
This is an example of a higher order effect. In your proposed encoding:
data Foo m = MkFoo
{ foo :: forall a. m a -> m a
}
Their operations have effectful actions in the negative position.
Thanks. I understand the definition; I don't understand the purpose. To me, foo
looks like a handler, not an effect.
I'm confused. Reader
is higher order because of local
. Writer
is higher order because of listen
. State
is higher order if you include StateM e.g. for exclusive state access if the underlying handler uses MVar
.
Right, I'm saying I don't understand why local
, listen
and StateM
are useful. If we want to continue the discussion maybe we should do so at the Bluefin issue tracker because this is becoming tangential to cleff
.
Sorry for not getting to this earlier; college got me extremely preoccupied.
The difference between a higher-order operation and a handler is that the former is an abstraction of the latter, just like how a (first-order) effect operation is an abstraction of a monadic action.
I will take a look at Bluefin some time; it seems interesting!
The difference between a higher-order operation and a handler is that the former is an abstraction of the latter, just like how a (first-order) effect operation is an abstraction of a monadic action.
@re-xyr Thanks. That's in line with what I was anticipating. I haven't yet understood the need to abstract over handlers. I will continue to give it consideration.
@evanrelf I see you gave my comment a "thumbs down". Is there something you could elaborate on? Are you upset with my lack of understanding, or my suggestion to move the discussion elsewhere? (If @re-xyr is happy to continue the discussion here, then that's fine by me. I just don't want to flood someone else's issue tracker with tangential discussion.)
I'm going to continue the discussion about higher-order effects at https://github.com/tomjaguarpaw/bluefin/issues/15.
This "direct style" approach to defining effects seems simpler than the one in the "Defining effects section". It avoids the GADT whose only purpose is to provide "hooks" onto which to hang the effectful operations. Instead, why not just define the effectful operations directly?
What do you think? Is this a viable approach?