js-proposal-algebraic-effects icon indicating copy to clipboard operation
js-proposal-algebraic-effects copied to clipboard

Should we implicitly inject the effects? No @@?

Open macabeus opened this issue 5 years ago • 4 comments

Currently we need to use @@ whenever we want to inject the inhered effects on a function call. Should we keep it?

If not, how to infer that we need to inject the effects on a function call? If yes, what should do if we call a function that launches an effect and we didn't inject the effects?

macabeus avatar Dec 21 '19 07:12 macabeus

I think it shouldn't be implicit, just as on async functions you need to use await to wait other asynchronous actions.

evaporei avatar Dec 23 '19 16:12 evaporei

In my opinion you have to use @@. Using async/await would break what is written is Dan's post.

The idea to use @@ is because (type-wisely speaking) you are returning two different types and it can break inference (even more!).

For example, say initially getName :: Void -> String, when you have a name = perform, you don't have a String anymore, you probably have a Effect<String>, (Effect<a>, where a is any possible types of an effect), and therefore getName is not Void -> String. It could be that getName was a Res<String>, where Res would either be String or a Effect<String>, or simplifying it: Either<String, Effect<String>>. I am using a mix of Haskell and F# in the notation xD

Would suggest to take a look at Railroad Oriented Programming (to get some inspiration)

luizperes avatar Dec 24 '19 20:12 luizperes

What if this spec was simply an extension for generators. And instead of perform we just use yield, but we add handle to try.

Then all generator functions can have effects injected. All the monadic semantics are already there.

Arguably async/await was just a specialization of a generator based coroutine, and that was largely required because promises weren't 100% monadic. But we can learn from that mistake and reuse the existing constructs.

I still think the new try / handle should be added, but as an extension of the existing generator spec.

If we did that, we wouldn't need @@ right?

JAForbes avatar Mar 30 '21 02:03 JAForbes

@JAForbes I think that using generators to handle the effect will take out this proposal's major advantage: no function color. Using generators, we need to add * at the beginning of the function and it returns only iterator values, and so it'll color our functions.

Also, updating the generator behavior to not need * neither always return iterator looks like a big change that I would prefer to avoid.

macabeus avatar Mar 30 '21 21:03 macabeus