Algebraic Effects for the Rest of Us • Hacker News Board

Re: Algebraic Effects for the Rest of Us

#41

Post by sirwhinesalot » Sat, May 30, 2026, 10:24 AM UTC

tome wrote: post #30

sirwhinesalot wrote: post #25

Earlier quoted context omitted.

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.

> 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 somethi…

We disagree that they're just continuations (only one of many possible implementation strategies) but agree they're nothing special ;)

Re: Algebraic Effects for the Rest of Us

#42

Post by tome » Sat, May 30, 2026, 10:25 AM UTC

captaincrowbar wrote: post #22

mrkeen wrote: post #5

Earlier quoted context omitted.

No, they are function colouring. That's the point. Someone writes a post lamenting red and blue functions, and everyone eats it up. Substitute colour for something meaningful and the idea becomes idiotic. "Top level function declares that it is non-blocking, but when I try to call a small blocking function from it, I have to change the declaration to blocking???" Yes, yes you do. Total functions can't call non-total…

‘Non-IO functions can't call IO functions.’ How do you handle logging then? If f() calls g(), how can I add logging to g() without having to change or recompile f() (and everything in the call stack above it)? ‘You can’t’ is not an acceptable answer.

Not sure why people are saying "you can't" when it seems to me the whole point of algebraic effects that you can. You can define g so that it has no ability to do "general IO", all it can do is yield log messages. Then f can call g in a way that turns the log messages into writes to stdout. For example, here's how you would do it in Bluefin:

    type Log = Yield String
    
    -- workWithLogging cannot do arbitrary IO!
    -- All it can do is yield log messages, which
    -- must be processed elsewhere.
    workWithLogging  ::
      (e1 :> es) =>
      Log e1 ->
      Int ->
      Int ->
      Eff es Int
    workWithLogging l x y = do
      yield l ("x was "  show x)
      yield l ("y was "  show y)
      let result = x + y
      yield l ("result was "  show result)
      pure result
    
    -- ghci> example
    -- x was 5
    -- y was 7
    -- result was 12
    -- 12
    example :: IO Int
    example = runEff $ \io -> do
      -- forEach determines how each log message
      -- should be handled.
      forEach
        (\l-> workWithLogging l 5 7)
        (\logMsg -> effIO io (putStrLn logMsg))

Re: Algebraic Effects for the Rest of Us

#43

Post by tome » Sat, May 30, 2026, 10:31 AM UTC

sebstefan wrote: post #21

I swear I'm not trying to be inflamatory, but this is the _worst_ programming language feature I could ever imagine. I'm not trying to be hyperbolic, if I try to reason about it there is nothing I can come up with that I would dislike more in the realm of recent features that have been pitched in the PL community I was already in the camp that try/catch is "considered harmful", I dislike the concept of having a secon…

> I dislike the concept of having a second, hidden, control flow that might get sprung up upon function callers, because it has side effects buried in the implementation of a callee that are not defined in the parameters or the returns

You might like my capability-based effect system for Haskell, Bluefin[1], then. If a Bluefin effectful function throws you can see it in the type system. If you want to have the capability to throw, you need to pass in an argument of type Throw. For example here "workWithThrow" can only throw an exception because it is passed the Throw capability.

    workWithThrow  ::
      (e1 :> es) =>
      Throw String e1 ->
      Int ->
      Int ->
      Eff es Int
    workWithThrow t x y = do
      let result = x + y
      when (result > 10) $ do
        throw t "Too big"
      pure result
    
    -- ghci> example
    -- Left "Too big"
    example :: Either String Int
    example = runPureEff $ try $ \t -> do
      workWithThrow t 5 7

[1] https://hackage.haskell.org/package/bluefin

Re: Algebraic Effects for the Rest of Us

#44

Post by sirwhinesalot » Sat, May 30, 2026, 10:34 AM UTC

sebstefan wrote: post #21

I swear I'm not trying to be inflamatory, but this is the _worst_ programming language feature I could ever imagine. I'm not trying to be hyperbolic, if I try to reason about it there is nothing I can come up with that I would dislike more in the realm of recent features that have been pitched in the PL community I was already in the camp that try/catch is "considered harmful", I dislike the concept of having a secon…

I agree but I also think it's important to point out that Algebraic Effects typically refers both to a runtime feature (the try/handle delineated continuation stuff) and also a type system feature.

The latter is very important because in your example it would not really be hidden. If your function does not have the "exn" effect, it cannot call functions that throw exceptions, full stop. Same with any other effect including IO if you want.

Basically function coloring taken to the extreme. In a statically typed language with statically typed effects you actually cannot get surprised, which was your major complaint.

Type systems that support algebraic effects also typically support row polymorphic effects (fancy generics) so you can make a function generic over "color", avoiding the "function coloring" problem.

Now, having said that, why did I say I agree with you? Well because algebraic effects are a lousy user-facing feature. You almost never want to implement your own handlers, at best you'll plug in a custom handler for the IO effect and that's about it. (And for exceptions of course, but that's just exceptions with extra steps)

Where they shine is for the language implementer. They provide a framework on which exceptions, generators, async/await and even prolog-like backtracking can be implemented, while (very importantly) defining how they compose. That's really the bit that makes them so interesting from a research point of view and why they might make it into the mainstream languages, even if the language doesn't actually ever expose them for you to use.

Re: Algebraic Effects for the Rest of Us

#45

Post by tome » Sat, May 30, 2026, 10:36 AM UTC

sirwhinesalot wrote: post #41

tome wrote: post #30

Earlier quoted context omitted.

> 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 somethi…

We disagree that they're just continuations (only one of many possible implementation strategies) but agree they're nothing special ;)

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 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).

Re: Algebraic Effects for the Rest of Us

#46

Post by sheept » Sat, May 30, 2026, 10:37 AM UTC

As the article notes, effects (at least as described in the article) are already possible in JavaScript using generators, as long as every calling function is a generator, which I assume the author finds problematic because generators are cumbersome.

I was wondering how well TypeScript can type generator-based effects. My hypothesis is that TypeScript can let you compose functions with effects, but it is not possible for it to narrow down that the result from an effect corresponds to the effect (i.e. the result of an effect will be any possible effect result used by the function).

My incomplete, untested attempt in TypeScript[0] tries to implement `enumerateFiles` and `withMyLoggingLibrary`. The type errors demonstrate TypeScript's limitation that it can't associate an effect call with its result.

[0]: https://www.typescriptlang.org/play/?#code/C4TwDgpgBAMg9gcwK...

Re: Algebraic Effects for the Rest of Us

#47

Post by oisdk » Sat, May 30, 2026, 10:40 AM UTC

u1hcw9nx wrote: post #37

brabel wrote: post #27

Earlier quoted context omitted.

The CL condition system always gets brought up when people unfamiliar with effects see effects for the first time (example: https://news.ycombinator.com/item?id=38813484 , another example: https://lobste.rs/s/12m2f0/algebraic_effects_another_mistake ). But while the condition system can do many things you can also do with effects, they cannot do everything. Here's another discussion on this: https://news.ycombinator.…

CL conditions do what you actually need if you program. CL gives you deterministic state, safe resource management etc. Nondeterminism is not a feature you want. Algebraic effects treat the execution stack (continuation) as data, you have total freedom over what you do with it. This flexibility is exactly where you get nondeterminism. This is how logic solvers or probabilistic algorithms work, but you don't want it a…

It’s pretty annoying to comment “this thing was already present in CL 30 years ago”, then to have someone correct you (pointing out that this is a common misconception, and algebraic effects are not equivalent to conditions at all), and then to respond not to admit you’re wrong but instead to say “algebraic effects are bad anyway because you shouldn’t want one of the extra features they give you (nondeterminism)”.

By the way, nondeterminism is not the only difference between the two.

Re: Algebraic Effects for the Rest of Us

#48

Post by bobogei81123 » Sat, May 30, 2026, 10:45 AM UTC

epolanski wrote: post #6

Everything he lists is solved by effect-ts [1] bar, obviously, the language support (effect has its own fiber-based runtime like ZIO's scala). I've been using it for 5+ years and my 4 men team can scale to supporting 6 different products (each running millions $ in business, sometimes daily), as we reuse the same patterns and architecture. This would not be possible without Effect, even though I'm lucky to have terri…

When I started a typescript server project, I spent quite some time - setting up dependency injection framework to pass context (tsyringe) - finding a good schema validation library (zod) - use neverthrow for typed error. - wrote a few withSpan, recordDuration OTEL helper functions.

Then I heard about Effect-ts, checked the doc, and realize that Effect-ts already has all these things, in a single package.

IMO Effect-ts is currently the most practical effect system right now. While it does not support resuming like in other algebraic effect languages, it is powerful enough to express common patters, but not too powerful so that the code becomes hard to understand.

I hope effect-ts gets more traction. The biggest obstacle to sell it right now is that the API doc is not great. I had to trace the source code several times just to see how a type is defined. I hope Effect-ts team is aware that more people will use it if it has a proper documentation.

Re: Algebraic Effects for the Rest of Us

#49

Post by sirwhinesalot » Sat, May 30, 2026, 10:51 AM UTC

tome wrote: post #45

sirwhinesalot wrote: post #41

Earlier quoted context omitted.

We disagree that they're just continuations (only one of many possible implementation strategies) but agree they're nothing special ;)

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 expres…

They're really just a protocol. You can implement them in various ways. They will always be some sort of delimited continuations but a "function call" or continuation passing style or anything of the sort does not have to be involved at all.

For example, let us say I don't allow "multi-shot" continuations like in your library, and I'm implementing Algebraic Effects in my own interpreted language.

One way I can implement effects and handlers is to have a handlers get registered in a stack, then when an effect is triggered, save the IP and current stackframe, search for the right handler and jump to it. "resume" then just resets the stackframe, pushes a value into the stack, and sets the saved IP.

(Only saw your edit after posting, sorry, but yes)

Re: Algebraic Effects for the Rest of Us

#50

Post by tome » Sat, May 30, 2026, 10:58 AM UTC

sirwhinesalot wrote: post #49

tome wrote: post #45

Earlier quoted context omitted.

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 expres…

They're really just a protocol. You can implement them in various ways. They will always be some sort of delimited continuations but a "function call" or continuation passing style or anything of the sort does not have to be involved at all. For example, let us say I don't allow "multi-shot" continuations like in your library, and I'm implementing Algebraic Effects in my own interpreted language. One way I can implem…

> They're really just a protocol.

Thanks, that clarifies where you're coming from. Is it possible to specify this protocol somehow, by defining an interface for it? Or by extending lambda calculus with the bits it needs?

(Maybe that's what the Koka folks do in their papers, and if so feel free to say, "yeah read their papers").