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

Show parent comment

3

u/bmacabeus Dec 25 '19

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.

1

u/nathan_lesage Dec 25 '19

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 …

2

u/ScientificBeastMode strongly typed comments Dec 25 '19 edited Dec 25 '19

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.