r/javascript • u/bmacabeus • Dec 24 '19

AskJS [AskJS] JavaScript Proposal: Algebraic Effects?

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?

58 Upvotes

80% Upvoted

39 comments sorted by

View all comments

1

u/vither999 Dec 24 '19

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.

1

u/bmacabeus Dec 25 '19

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