6 ms·

I was completely baffled by "algebraic effects" for years. They looked far too confusing for me to want to spend my time on them, and took the "Don’t feel like

by tome 4mo ago

I was completely baffled by "algebraic effects" for years. They looked far too confusing for me to want to spend my time on them, and took the "Don’t feel like you have to [get curious about them]" approach. But then at some point it struck me: underlying all these effect systems is just passing stuff in. So I developed my own effect system for Haskell, Bluefin[1], based on capabilities, which means the "capability to perform some effect" is represented by just passing stuff in (that is, a function can do some effect as long as it has been passed the capability to do it). From this point of view it's hard to understand the excitement over "resume with" and "the part you can’t do with try / catch. It lets us jump back to where we performed the effect, and pass something back to it from the handler". Programming languages have had that feature since forever: a "resumable exception" is a "function call". A dynamically chosen "resumable exception" is the call of a dynamically chosen function, i.e. the argument to a higher order function. So I don't know why people love the complexity around "algebraic effects". Maybe the mystique has a certain allure. But if you want the most straightforward possible approach I can recommend you try out Bluefin. I'm happy to answer questions on the issue tracker[2]. (Caveat: Bluefin is able to simplify things dramatically by dropping support for "multi-shot" continuations. But mostly you don't want multi-shot continuations.) EDIT: I was too pessimistic, bazoom42 has noticed this :) https://news.ycombinator.com/item?id=48334067 https://news.ycombinator.com/item?id=48334067 [1] https://hackage.haskell.org/package/bluefin https://hackage.haskell.org/package/bluefin [2] https://github.com/tomjaguarpaw/bluefin/issues/new https://github.com/tomjaguarpaw/bluefin/issues/new

jacobp100 4mo ago
Continuations (“function calls”) reduce the amount of optimisations you can do around memory - both space wise and computationally
- tome 4mo ago
  Not sure I follow what you're trying to say. Can you elaborate?
sirwhinesalot 4mo ago
Equating "algebraic effects" with "continuations" is like saying "if" is just "goto" (which isn't even true, e.g., an if can turn into a cmov or whatever). The only mystique around algebraic effects is the same mystique there is around monads. I don't know if people have started equating algebraic effects to burritos yet but that's a pretty good way to take something simple and turn it into something confusing.
- tome 4mo ago
  > Equating "algebraic effects" with "continuations" is like saying "if" is just "goto" Fair enough. But are you responding to something I said? I didn't make that equation. > The only mystique around algebraic effects is the same mystique there is around monads. I don't know if people have started equating algebraic effects to burritos yet but that's a pretty good way to take something simple and turn it into something confusing. Ah, are you saying that fundamentally there isn't really much to algebraic effects and they're much simpler than they're made out to be? If so then it perhaps we agree?
  - sirwhinesalot 4mo ago
    We disagree that they're just continuations (only one of many possible implementation strategies) but agree they're nothing special ;)
    - tome 4mo ago
      I don't think I said they're just continuations. In fact I'm trying to make the point that they're mostly just function calls (and I think in my career I've come across one case where I wanted something beyond function calls (for a constraint solver)). There are "multi-shot" continuations (whether you consider that interface or implementation I don't really mind), which have behaviour than function calls can't express, but I don't know of any algebraic effects beyond that. What do you think algebraic effects are, if they're not continuations? EDIT: Ah, based on your comment at https://news.ycombinator.com/item?id=48334737 https://news.ycombinator.com/item?id=48334737 you might say they're a feature of an intermediate language? So you might take a surface language and "compile to an intermediate language of lambda calculus + algebraic effects", without specifying how that intermediate language is implemented (because it may not even be implemented, per se).
brabel 4mo ago
A real effect system allows you to do things like NOT continue execution after using the effect (like the error effect does - if you "implement" this by using Exceptions, you're not using effects at all, just using Exceptions with extra steps) or only continuing it after some asynchronous work happens (the Future effect), or even "continue" execution several times. That just cannot be done with "just passing stuff in". You still don't seem to have understood effects.
- tome 4mo ago
  Thanks for your response. Perhaps I'm missing some fundamental things. Could you help? > A real effect system allows you to do things like NOT continue execution after using the effect Right, Bluefin's Request allows you to do that too. For example here is an example of handling the request by continuing or not, depending on what the value yielded to the Request is. example :: Either String () example = runPureEff $ try $ \ex -> do forEach ( \r -> do request r True request r True request r False request r True request r True ) ( \case True -> pure () False -> throw ex "Stopped" ) > if you "implement" this by using Exceptions, you're not using effects at all, just using Exceptions with extra steps Not sure I follow that. Above you can see I used an exception (Bluefin's Throw capability), but I couldn't have used only an exception because that would have aborted unconditionally. What am I missing here, that makes "using Exceptions" "not using effects at all"? > only continuing it after some asynchronous work happens (the Future effect) I'm not really sure what "a Future effect" is, but I don't see how it's not something that can be run as a function call, at least in Haskell. > or even "continue" execution several times Right, these are the multishot continuations which Bluefin doesn't support. I haven't discovered many particularly compelling use cases for multishot continuations but would be very interested in finding some. The developer of the Kyo effect system for Scala, Flavio Brasil, suggested parsing, with multiple parse results, which makes sense. I'm also not entirely sure Bluefin couldn't simulate common use cases of multishot continuations with threads, but I haven't thought about it very hard. > You still don't seem to have understood effects. Possibly true, and part of my puzzlement! I'm always happy to try to improve my understanding. Can you help me see what I've missed?

by tome 4mo ago

jacobp100 4mo ago

Continuations (“function calls”) reduce the amount of optimisations you can do around memory - both space wise and computationally

tome 4mo ago
Not sure I follow what you're trying to say. Can you elaborate?

sirwhinesalot 4mo ago

Equating "algebraic effects" with "continuations" is like saying "if" is just "goto" (which isn't even true, e.g., an if can turn into a cmov or whatever). The only mystique around algebraic effects is the same mystique there is around monads. I don't know if people have started equating algebraic effects to burritos yet but that's a pretty good way to take something simple and turn it into something confusing.

tome 4mo ago
> Equating "algebraic effects" with "continuations" is like saying "if" is just "goto" Fair enough. But are you responding to something I said? I didn't make that equation. > The only mystique around algebraic effects is the same mystique there is around monads. I don't know if people have started equating algebraic effects to burritos yet but that's a pretty good way to take something simple and turn it into something confusing. Ah, are you saying that fundamentally there isn't really much to algebraic effects and they're much simpler than they're made out to be? If so then it perhaps we agree?
- sirwhinesalot 4mo ago
  We disagree that they're just continuations (only one of many possible implementation strategies) but agree they're nothing special ;)
  - tome 4mo ago
    I don't think I said they're just continuations. In fact I'm trying to make the point that they're mostly just function calls (and I think in my career I've come across one case where I wanted something beyond function calls (for a constraint solver)). There are "multi-shot" continuations (whether you consider that interface or implementation I don't really mind), which have behaviour than function calls can't express, but I don't know of any algebraic effects beyond that. What do you think algebraic effects are, if they're not continuations? EDIT: Ah, based on your comment at https://news.ycombinator.com/item?id=48334737 https://news.ycombinator.com/item?id=48334737 you might say they're a feature of an intermediate language? So you might take a surface language and "compile to an intermediate language of lambda calculus + algebraic effects", without specifying how that intermediate language is implemented (because it may not even be implemented, per se).

brabel 4mo ago

A real effect system allows you to do things like NOT continue execution after using the effect (like the error effect does - if you "implement" this by using Exceptions, you're not using effects at all, just using Exceptions with extra steps) or only continuing it after some asynchronous work happens (the Future effect), or even "continue" execution several times. That just cannot be done with "just passing stuff in". You still don't seem to have understood effects.

tome 4mo ago
Thanks for your response. Perhaps I'm missing some fundamental things. Could you help? > A real effect system allows you to do things like NOT continue execution after using the effect Right, Bluefin's Request allows you to do that too. For example here is an example of handling the request by continuing or not, depending on what the value yielded to the Request is. example :: Either String () example = runPureEff $ try $ \ex -> do forEach ( \r -> do request r True request r True request r False request r True request r True ) ( \case True -> pure () False -> throw ex "Stopped" ) > if you "implement" this by using Exceptions, you're not using effects at all, just using Exceptions with extra steps Not sure I follow that. Above you can see I used an exception (Bluefin's Throw capability), but I couldn't have used only an exception because that would have aborted unconditionally. What am I missing here, that makes "using Exceptions" "not using effects at all"? > only continuing it after some asynchronous work happens (the Future effect) I'm not really sure what "a Future effect" is, but I don't see how it's not something that can be run as a function call, at least in Haskell. > or even "continue" execution several times Right, these are the multishot continuations which Bluefin doesn't support. I haven't discovered many particularly compelling use cases for multishot continuations but would be very interested in finding some. The developer of the Kyo effect system for Scala, Flavio Brasil, suggested parsing, with multiple parse results, which makes sense. I'm also not entirely sure Bluefin couldn't simulate common use cases of multishot continuations with threads, but I haven't thought about it very hard. > You still don't seem to have understood effects. Possibly true, and part of my puzzlement! I'm always happy to try to improve my understanding. Can you help me see what I've missed?