Should we implicitly inject the effects? No @@? about js-proposal-algebraic-effects

[evaporei]

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

[luizperes]

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)

[JAForbes]

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?

[macabeus]

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