#Algebraic Effects for Control-Flow

1 messages · Page 1 of 1 (latest)

strange summit
#

Hi everyone đź‘‹

I am fairly new to OCaml and currently looking at the new effect system. In the docs, effect handlers are described as a generalisation of exception handlers. This reminded me about the common advice to not use exceptions to model control flow (with which I personally definitely agree). Now I’m wondering if this applies in a similar way to algebraic effects. What are your opinions on using effect handlers to model control flow?

To make it more concrete, think about a reasonably complex board game (i.e. chess) which is supposed to have multiple different user interfaces. It’d be great to contain as much game logic as possible in the core module, without leaking any view-specific assumptions in there. To achieve that, we could introduce an effect for the user interaction, which is performed by the core module and handled separately for each UI-implementation. This lets us model the full game-flow in the core module in a subjectively natural way. Whenever we expect the user to interact, we just perform our effect instead of interrupting the current process in an intermediate state.

I hope this is somewhat understandable and I am excited to hear about your thoughts on this. Please correct me, if you find I made inaccurate assumptions.

Cheers ✌️

pale turtle
#

The use case you're describing, supporting multiple implementations on top of an abstract interface, seems like it would be perfect for functors. It's not clear to me how using effects would benefit this specific scenario.

mild estuary
#

functors are better for this particular usecase, but this might be worth a read as a quick primer to effects

pale turtle
#

Something else just to add to the discussion is that in OCaml the idea that "exceptions shouldn't be used for control flow" isn't really dogma like it is in other languages. Using an exception, for example, to break out of a loop isn't necessarily considered bad practice. In comparison to exceptions, effects are kind of the opposite in the sense that performing an effect doesn't break a loop or otherwise disrupt the control flow. Effects are more designed around handling internal state (e.g. a scheduler queue).

mild estuary
#

i’d say exceptions are a last resort

#

there are enough tools like recursion and monads that actually breaking control flow only happens when it needs to

strange summit
#

Thanks for the suggestions. Functors are definitely appealing here. Just wanna explore some ideas around the effect system and understand potential use cases for them.

Besides this potentially inadequate example, I’m really trying to understand to what degree it is legitimate to move control flow into the effect system (esp. thinking about user input). I think you make a good point, about the fact that effects don’t necessarily break the loop, @pale turtle .

pale turtle
#

I hope I didn't sound too critical. You can certainly use effects for stuff like what you described, although IMO they're likely going to be more complex than the other ways. Regarding control flow specifically, you might be interested in what the manual calls "inversion of control" with effects https://ocaml.org/manual/5.2/effects.html#s%3Aeffects-sequence basically where producers and consumers can both control any data structure with only a couple of functions

mild estuary
#

effects right now are (imo) pretty hard to use outside of schedulers. they’ll get more obviously useful when they have pattern matching syntax (5.3) and are typed (???)

strange summit
#

@mild estuary I definitely agree, writing effect handlers atm feels quite cumbersome. Just looked at the new syntax, that looks much more natural. What do you mean by the effects being typed? Aren’t they typed already? 🤔

pale turtle
#

Typed effects means that the type checker will track which expressions perform effects and not handling an effect will be a type error.

#

Right now, there’s no way to know (from a type signature) that a function performs an effect or handles an effect

#

It’s part of the original theory of algebraic effects which didn’t make it into the initial release for OCaml

strange summit
#

Oh I see.. thanks for the explanation!