Algebraic Effects for the Rest of Us

Post by sweetsocks21 » Sat, May 30, 2026, 11:43 PM UTC

tome wrote: post #36

brabel wrote: post #26

Earlier quoted context omitted.

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…

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

  effect Sched =
    yield : unit -> unit
    fork  : (unit -> unit) -> unit
  end
  
  let mut run_queue = []
  let enqueue t = run_queue := List.concat run_queue [t]
  
  let dequeue () =
    match run_queue with
    | [] -> ()
    | t :: rest ->
      run_queue := rest;
      t ()

  let rec spawn task =
    handle
      task ()
    with
    | return _ -> dequeue ()
    | yield () k ->
      enqueue (fn () -> resume k ());
      dequeue ()
    | fork f k ->
      enqueue (fn () -> resume k ());
      spawn f

  let run main = spawn main

  let worker name steps =
    let rec loop i =
      if i > steps do ()
      else do
        print $"{name}: step {i}";
        perform yield ();
        loop (i + 1)
      end
    in
    loop 1
  
  let () =
    run (fn () ->
      print "main: starting";
      perform fork (fn () -> worker "A" 3);
      perform fork (fn () -> worker "B" 3);
      print "main: forked workers, now yielding";
      perform yield ();
      print "main: done")

  main: starting
  A: step 1
  B: step 1
  A: step 2
  main: forked workers, now yielding
  B: step 2
  A: step 3
  main: done
  B: step 3

Post by tome » Sun, May 31, 2026, 9:56 AM UTC

hutao wrote: post #81

tome wrote: post #78

Earlier quoted context omitted.

Ah, thanks, maybe this holds a clue! (Clearly I have been interested in getting to the bottom of this for a while.) So maybe an "algebraic effect" is one that's isomorphic to a free monad of a functor that itself is an algebraic data type. That seems to give an unambiguous specification for what it means to handle an effect (a natural transformation) and to take a "free product" of effects (sum the functors). On the…

This is the gist of Andrej Bauer's paper: - An algebraic theory consists of a "signature" (specifying a set of operation symbols with their arities) and a set of equations about those operations. An algebraic theory is purely syntactic, and does not give meaning to the operations or equations. - An interpretation of an algebraic theory maps each operation symbol to a concrete mathematical object. It maps syntax to se…

Post by tome » Sun, May 31, 2026, 11:05 AM UTC

sweetsocks21 wrote: post #82

tome wrote: post #36

Earlier quoted context omitted.

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

I think the parent may be getting at the continuation aspect of effects? Effect systems make the stack a first class object you can reuse, I think a standard example is implementing a scheduler. I'm not familiar with your Bluefin library so maybe it already handles this: effect Sched = yield : unit -> unit fork : (unit -> unit) -> unit end let mut run_queue = [] let enqueue t = run_queue := List.concat run_queue [t]…

Post by noelwelsh » Sun, May 31, 2026, 8:02 PM UTC

tome wrote: post #85

noelwelsh wrote: post #79

Earlier quoted context omitted.

You can precisely define any particular model, but not all work in the area shares the same model. I think you know about the capability-passing model, which is quite different to the algebraic effects (e.g. row types) models. The general ideas are: * effects are handled by handlers (called capabilities in the capability-passing model) * function signatures describe the effects that are used * effectful code is writt…

Thanks! This begins to make more sense to me > effects are handled by handlers OK, and in the general case a handler allows its body to "perform" an action, and when the action is performed it has the ability to "respond" to it in (in some cases) a very flexible way, running it never, or multiple times, or in a modified environment, or possibly even passing it out of the scope of the handler entirely. > function sign…

Post by codebje » Mon, Jun 01, 2026, 2:26 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.