Algebraic effects

I’ll start off by posting some links, for those that are unfimiliar on the subject (like me, lol)

I want to pull out a key quote from “Algebraic Effects for the Rest of Us”:

I think they could be a great fit for a language where mutation is uncommon, and where the standard library fully embraced effects. If you primarily do perform Timeout(1000), perform Fetch('http://google.com'), and perform ReadFile('file.txt'), and your language has pattern matching and static typing for effects, it might be a very nice programming environment.

Maybe that language could even compile to JavaScript!

In my opinion ReScript has a great opportunity to be that language and also solve cross cutting concerns like async/await and generators in the process. What are your thoughts?

11 Likes

Would love to have them, of course.
But as a realist, I only see the limited time the ReScript team has got and simply cannot imagine they are capable (in terms of time of course) to do such a R&D-heavy task.

Maybe it’s better to wait for OCaml landing the effect system and then build on top of it, and simplify it/adapt it to better fit the JS scope.

2 Likes

Relude use is not encouraged. I can’t see how algebraic effects would be embraced in such a setting.

1 Like

I’m not sure what point you’re trying to make here. Are you commenting on the conservative approach the core team takes in adopting FP idioms? It reads as a little entitled and derivative to me so would be good if you could expand a little.

Yes, I’m trying to point out that the team emphasizes a practical mix of imperative and functional programming, and has repeatedly mentioned in this forum that topics you might see in Haskell are not a focus of ReScript. I generally get the impression that if it would take someone coming from Typescript more than a few hours to learn, then the team would prefer not to use it as a core idiom in ReScript.

That’s fair. I do see alg effects as a more attractive proposition than many other FP features in the JS community, but that’s just anecdotal experience.

I see lots of analogies to Promises actually. They’re easy to grok for JS devs familiar with imperative programming but have a FP history and are monads under the hood.

Check this out Uncurried by default? - #30 by ryyppy

My personal conclusion after this experience (community, libraries, specs, PLs, working on projects) is that this particular part of the JS community will probably stay niche because of many different (social) issues. I saw myself, and many other FP-JS enthusiasts, ending up in a pretty weird echo-chamber, where we were all repeating back our positive opinions about category theory, monads, functional composition, pureness etc, while in the meantime, we completely ignored the rest of the JS community and all the folks that didn’t understand our (abstract thinking) mindset.

Anyways, now with ReScript we have a real chance on taking the practical parts of all that FP jazz, remove the fancy words, polish the syntax in a more JS friendly manner, and reduce the number of concepts to learn so ppl can focus on the IMO “more relevant” parts of the language.

I think it’s fair to say this has been the approach of the ReScript team to FP concepts overall.

2 Likes

I think you can sell effects to (parts of) the JS community now, since there are React Hooks.
Maybe spare the “algebraic” and explain how async/await can be done with an effect as well.

1 Like