js-proposal-algebraic-effects
js-proposal-algebraic-effects copied to clipboard
Should we implicitly inject the effects? No @@?
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?
I think it shouldn't be implicit, just as on async
functions you need to use await
to wait other asynchronous actions.
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)
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 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.