Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should we implicitly inject the effects? No @@? #3

Open
macabeus opened this issue Dec 21, 2019 · 4 comments
Open

Should we implicitly inject the effects? No @@? #3

macabeus opened this issue Dec 21, 2019 · 4 comments
Labels

Comments

@macabeus
Copy link
Owner

macabeus commented Dec 21, 2019

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 macabeus added the enhancement New feature or request label Dec 21, 2019
@macabeus macabeus changed the title Inject implicitly the effects Should we implicitly inject the effects? No @@? Dec 23, 2019
@macabeus macabeus added spec and removed enhancement New feature or request labels Dec 23, 2019
@evaporei
Copy link
Contributor

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

@luizperes
Copy link
Collaborator

luizperes commented Dec 24, 2019

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)

@macabeus macabeus mentioned this issue Jan 3, 2020
@JAForbes
Copy link

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
Copy link
Owner Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants