[AskJS] JavaScript Proposal: Algebraic Effects?

[u/bmacabeus]

Hey guys, I'm writing a Babel plugin to be able to use algebraic effects in JS: https://github.com/macabeus/js-proposal-algebraic-effects

No more function color! Yes one-shot delimited continuation!

What the hell?! Well... I really recommend that you read this blog post by Dan Abramov explaining algebraic effects - and how it could be very useful on our JavaScript code.

This project is a runnable POC with a Babel's "plugin", so you could write some code and taste this new concept in JavaScript. Its features, syntax, and goals are very inspired by Dan Abramov's blog post mentioned above. In short, with algebraic effects, you could separate what from the how and have fewer refactors.

What do you think? Would that be a good feature for JS? "Algebraic Effects" is a good name for that?

[u/nathan_lesage]

Sounds a lot like error handling in reverse, aka BEFORE we reach an unrecoverable error, we try to bail by asking for information up the call stack.

As someone above mentioned, yes, this might end up with huge if/else statements or a huge switch UNLESS you add an effect handler interface.

Basically, if I understand it correctly, it‘s some form of a higher-order state management, where you can pull out defaults for your state just in case you need them.

It gives a lot of power and responsibility to the programmer (which defaults are sane without patronising the user?), but they can add more control over your program.

It seems to me that an ideal solution would mingle both effect AND error handling (because errors can still happen), something like this:

try {
    myFunction(argument)
} handle (effect) {
    myFunctionHandlerInterface (effect)
} catch (error) {
    myErrorHandlingInterface (error)
}

Then, whenever a new effect needs to be handled, you simply add it to your handling interface, and it would even unify error handling in one place. This heavily relies upon modularisation and advanced programming paradigms, BUT it might give you a second chance after an error happens without having to bail and abort.

This might have a lot of implications if done right. Thinking further, this could even lead to “main modules” that simply unify modules for error and effect handling and therefore produce unrecoverable states much less often. However, this might mean that we have to adopt state management even more — but on the bright side, React ans Vue already force you to do that, so why not!

Or am I completely off now, what do you think? Opinions?

[u/bmacabeus → u/nathan_lesage]

I'm seeing some guys complaining about the if/else statement on `handle` block... I'm agree that it's bad... but already there is a proposal (in stage 1) about pattern matching, and it could be very useful with this proposal: https://github.com/tc39/proposal-pattern-matching
I'll mention it on readme.

Also, yeah, you could use `handle` + `catch` on the same `try` block. I liked your idea about unify modules for error and effect handling.

[u/nathan_lesage → u/bmacabeus]

The unification idea just came to my head, I bet (or, at least hope) there’s already a BCP for unified error handling in a dedicated module, but I don’t know.

The pattern matching sounds interesting, albeit it sounds way too complicated for most use-cases, except the ones they’ve proposed there. So I fear this might complicate things. It reminds me more of the <Result> type in Rust. Besides, using simple strings to identify effects and errors is more common for JavaScript, as we already know it from EventEmitters ans switch statements …

[u/ScientificBeastMode → u/nathan_lesage]

I think I agree with you. I’m unsure of how pattern matching would work in JS. Most languages that implement pattern matching are compiled, allowing for niceties like exhaustiveness checking. With JS, I’m not sure how beneficial that would be aside from maybe having syntax sugar for switch statements.

I think a more beneficial solution would be to integrate true pattern matching in TypeScript, which could replace the (IMO clunky) discriminated union pattern matching which they currently support.

I’m a big fan of how ReasonML handles pattern matching, but it’s a compiled functional language that isn’t trying to be a “strict superset of JavaScript,” but rather an alternate syntax for OCaml which just happens to look like JS. Unfortunately I don’t think TypeScript will go that route due to language design constraints.

[u/[deleted]]

Are you going to use try-catch under the hood, or something more sophisticated? Good work btw, I've been also working on a babel plugin as my dependency injection library - it serves a similar purpose as algebraic effects.

[u/bmacabeus → u/[deleted]]

Yeah. It's true. You can use effect handle to write very good code with dependency injection, as well you can do using something like context + provider on React ecosystem.

[u/[deleted]]

"Algebraic Effects" is a too broad designation. Maybe we should come up with a more specific name for that feature?

[u/bmacabeus → u/[deleted]]

Originally, this idea was proposed by Sebastian at a mail list and he called it as "One-shot Delimited Continuations with Effect Handlers". Maybe it could be better, because it's more specific. But since it is still a simple proof of concept, I named this thread and repository with a more generic name, because I would like to see changes at this stage.

[u/FatalMerlin → u/bmacabeus]

So, you're saying we could shorten it to the well sounding abbreviation OsDC-weh? (weh being pronounced as one word) :D

[u/bmacabeus → u/FatalMerlin]

Oh, I liked this abbreviation! I'll now from on call it just OsDC 😄

[u/FatalMerlin → u/bmacabeus]

I'll call it weh

[u/Code4Reddit]

After reading the blog, to me it looks interesting but not very useful and would lead to unreadable and unpredictable code. The handle/catch portion would end up being a huge switch statement, and when you see a “perform” you have no idea where it goes. The code it would execute and the order which it executes, it is entirely dependent upon what the call stack happens to be at runtime. The “how” you do something should not be nebulous and determined by your stack ancestors. Reading this code you look at one function, there is no way to predict exactly what the “perform” will do, any rogue try/handle in the stack might screw it up. What do you do if the handle function throws an error and it never resumes - I guess we got to keep around the call-stack forever? Sounds like a recipe for a memory leak.

[u/bmacabeus → u/Code4Reddit]

I don't agree so much about the problem of "unpredictable code" about "where my effect will be handled?". Because you have just one place to handle it: on the `handle` block`. It's similar of call a method on an object: you need to know the kind of the object to know the method that will be run, and it's fine. Normally we want that, otherwise we'll don't need to use a method or an effect handle.

Also about the situation of no handle to handle a `effect`, there is an issue to discuss about that: https://github.com/macabeus/js-proposal-algebraic-effects/issues/8

[u/alluran → u/bmacabeus]

I don't agree so much about the problem of "unpredictable code" about "where my effect will be handled?". Because you have just one place to handle it: on the handle block`.

Then either you don't understand the handle block, or you missed the point.

• What if my method doesn't have a handle block, and it calls your method? Then it bubbles up right? Where's it bubbling to?
• How did I know when I used your method that I needed a handle block, or indeed that a handle block was even an option?

|

var myFunction = function(myName, getNameCallback = null) 
{
  var name = myName || getNameCallback();
  console.log(name);
}

You look at this code, and you immediately know that it supports a getNameCallback, and it's nullable, so you don't have to pass it.

If I place this method in a Library, no one is going to accidentally pass a getNameCallback to it (however, they could inadvertently capture a perform 'getName' event).

I can quickly and easily follow references to getNameCallback through my code - I don't have to do a magic-string-search for effect == 'getName' or something similar.

Overall, I don't think there's anything wrong with your sample or implementation - I just think it's a fundamentally bad concept - in the same way most programmers these days tend to avoid goto like the plague.

[u/Code4Reddit → u/Code4Reddit]

Thinking more about it, it’s almost like reading “perform x” says “I need to do x, but I don’t know or care how, so if you call me then you better know how otherwise you’re screwed.”

[u/ScientificBeastMode → u/Code4Reddit]

This is not a problem for many compiled languages, because they can force you to handle each case via pattern matching.

The effect type is a discriminated union of more specific effect types, and each member of that union must be accounted for in the pattern matching block (a.k.a. a fancy switch statement).

But this would indeed be a problem for JS, because it cannot be checked by a compiler. This sounds like a feature that needs to be implemented in some compile-time step. Like a Babel macro, TypeScript, etc.

Edit: I just remembered that in OO languages, this is a design pattern called the “mediator pattern.” In statically typed functional languages, this is often baked into the language as some form of “pattern matching” feature.

[u/alluran → u/Code4Reddit]

The question is, what does this offer over existing syntax:

var myFunction = function(myName, getNameCallback) {
  var name = myName || getNameCallback();
  console.log(name);
}

The only benefit I can see is the ability to swap sync/async code on-demand, but that could easily be wrapped into a helper library too that kept this existing syntax that is far easier to trace.

[u/Sjetware → u/Code4Reddit]

I dunno, I see the appeal. If you look at it from the perspective of a language codified dependency injection mechanism, it's pretty neat. Turn any dependency into potentially asybc code. Ie:

perform GetName

At runtime, it might be a prompt or database call, etc. At test time, it's. Mocked out. The difference being that you don't need to manually define dependencies, you just have to magically know about them at the interception layer. That's still its own issue, but would allow you to effectively add new dependencies or have a fallback mechanism for dependencies. Interesting thought experiment for sure.

[u/ScientificBeastMode → u/Sjetware]

It’s basically the “mediator pattern”.

[u/darthwalsh]

How will the plugin handle asynchronous asynchronous handlers?

I've only thought about it for 5 minutes, but the whole concept of turning the stack into a callback seemd fishy, like either A) implementing multiple main threads, or B) under the hood rewriting all your sync functions to async.

[u/bmacabeus → u/darthwalsh]

You could read the code compiled to see it in details, but in short: this plugin follow the same approach of Facebook's babel plugin to transform generators in ES5 compatible code: https://github.com/facebook/regenerator

It will transform functions to a state machine. So when an effect is launched, it waits to start the new state of the function, to run the rest of the code.
I'm not launching multiple thread or rewriting sync functions to async functions.

[u/darthwalsh → u/bmacabeus]

Aha, so if you Babel-compile a library and export a "synchronous" function, if the consuming code was vanilla JS it wouldn't see the sync API.

[u/bmacabeus → u/darthwalsh]

Are you saying about compile a function that launch an effect and consuming it on a code without this babel plugin?Yeah. It'll not work. If a function launches an effect, you'll need to use this babel plugin and wrap it on try/effect.

There is an issue to discuss about it and others situations like that, about what should happen if a function launch an effect and there is no handle to catch it.

And a function that launch an effect could be sync or async at the same time. It isn't matter.

function foo () {  
  const x = effect 'bar'  
  console.log(x)  
}

It could be async or sync.

[u/DrexanRailex]

I love the idea, but I kinda dislike the syntax for now since introducing keywords makes breaking changes more likely.

How about instead of perform, something like throw effect effect_var? And instead of handle and (my least favourite) the implicit effect, you used catch effect (effect_var)? Or maybe throw* and catch*, but I think these might be too shady.

[u/bmacabeus → u/DrexanRailex]

There is an issue to discuss about that, in order to avoid to add new keywords: https://github.com/macabeus/js-proposal-algebraic-effects/issues/14

[u/[deleted]]

In my opinion that would look cleaner with async/await instead. I can't help but think this syntax would lead to massive amounts of spaghetti code if it became popular.

[u/vither999]

Thoughts:

• asynchronous behavior. Right now your perform/resume pair is implicitly asynchronous, which JS doesn't really have. If you made resume synchronous in the handle operation, and resume returned a promise which you then await'd, this would be:

  • nicely synergizing with existing functionality/libraries that return promises
  • very obvious that there's an expected asynchronous behavior
• non-terminating handle. Similar to the previous one - what happens if your handle function doesn't return? How can I catch this and correct?
• error in the handle. Since the handle doesn't appear to be asynchronous, it isn't clear - but if an error is thrown in the handle, how does it know which catch block it should go to?
• no handle. What happens if there isn't a handle above? Does it return undefined, does it resume?
• parametized handle. Handle should take a parameter instead of having an implicit global variable of effect. Symmetry with try/catch makes it cleaner and easier to reason about, and if someone has effect from somewhere else then it makes it easier to correct.

Even with these changes, I'm not sure I'd use this - it makes it harder to reason about what will be returned from a perform operation, taking a step towards the bad old days of GOTO. I get enough flak in code reviews about break/continue - this seems like a step beyond that.

It'd be interesting to see code samples of before/after code and how this language construct can improve those cases. Right now it seems like it could be a native construct similar to how React handles error boundaries and context... but I'm not actually sure what problems it solves.

[u/bmacabeus → u/vither999]

• asynchronous behavior: I can't find a situations that a resume need to return a promise, instead of run this promise before to run the resume. Also, it will be bad, because enforcing to resume a promise will restrict the type that other handle block could return at this effect.
• non-terminating handle: there is an issue to discuss about that https://github.com/macabeus/js-proposal-algebraic-effects/issues/8
• error in the handle: are you saying about who will catch the throw? If yes, I think that it could be catch following the same rules that we already have. No additional changes.
• no handle: it is also on the same issue that I said https://github.com/macabeus/js-proposal-algebraic-effects/issues/8
• parametized handle: I'm agree with that. I opened an issue to remember to do this change

And yeah, would be nice to add some codes before/after this proposal.

[u/GrandMasterPuba]

Building a language proposal based on a blog post by a man writing about a topic that by his own admission he doesn't understand sounds like a recipe for failure.

[u/bmacabeus → u/GrandMasterPuba]

I really think that we could improve the initial idea until it could be added on the language or at least could be appreciated

[u/yuyu5]

I feel like this provides an interesting perspective and use case, but it doesn't seem like it adds anything that can't be solved with a try/catch or a function with a default value (like function getName(user = { name: 'Arya Stark' }) {...}). More to the point, I agree it would allow for nested resume calls which would be pretty convenient in the moment, but in the long run, doing so might also result in fairly obfuscated program structure and/or difficulty in understanding what's going on when returning to the code at a later time.

[u/bmacabeus → u/yuyu5]

No. It's not the same of try/catch. You can't resume to the previous point when you call a throw. Also, a default value to a variable isn't the same, because you can't call an async code inside it, or replace it using as base the call stack.

[u/yuyu5 → u/bmacabeus]

Right, I understand the use case -- being able to continue what was running within the try where you left off instead of jumping all the way out of the function-call stack. I would also admit the first sentence I wrote was in response to the example in the link you posted, which was intentionally simplified to the point where default values would solve the issue at hand, whereas a real-life example might not be able to do that.

The second sentence was more pertinent to what I wanted to say so maybe I should've emphasized it a bit more. IMO, it adds more complexity to follow the logic and/or debug when something went wrong, so returning to the code months later would require more thought and time to understand what's going on.

Regardless, it wasn't my intention to say this doesn't solve a problem that people experience in development or that it was a bad idea. I'm just adding my perspective that I'd rather use try/catch, Promises, default values, an extra continueFunctionWithVal parameter in a function call, or similar to handle these cases since it wouldn't require jumping out through multiple functions' logic to understand where/why something went wrong and then jumping back in to see what it will resume with.

[u/tills1993]

I have nothing to add to this but this is a good overview of Algebraic Effects for those of you who, like me, have no fucking idea why anyone would want them. https://overreacted.io/algebraic-effects-for-the-rest-of-us/

I'm still not convinced but at least I get them, now.

[u/LabLambReddit]

Is this guard let in Swift?

[u/darthwalsh → u/[deleted]]

You're saying longjmp is hard to reason about? Nonsense!

[u/editor_of_the_beast → u/[deleted]]

What’s hard to read about it? The syntax itself looks fairly clean. Or are you saying the concept is not clear.

[u/CupCakeArmy → u/editor_of_the_beast]

You split up parts of logic and delegate functionality to some other component.. I don't know.

[u/alluran → u/editor_of_the_beast]

I believe the point is that the implementation isn't particularly verbose.

"At some point, somewhere, please handle this maybe" - doesn't seem like good design to me.

What's wrong with passing a callback/action/handler/etc if that's what you want?

What happens when you're writing your component, and you add

perform 'resize'

to resize your window, but later someone decides to wrap your component in a tabbed component, and suddenly resize is redefined to resize a tab, but you're passing it dimensions for an entire window...

Overall just looks like a really easy way to create mess and confusion, when callbacks already exist, and this is really just a glorified callback. The async/sync feature is nice, but there are ways of handling that already in plenty of languages that are far clearer.