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

Switch from Eff to IO #3080

Closed
paf31 opened this Issue Sep 20, 2017 · 23 comments

Comments

Projects
None yet
@paf31
Member

paf31 commented Sep 20, 2017

Optimizer rules need to be updated as part of the switch to IO as the default effect monad.

@paf31 paf31 added this to the 0.12.0 milestone Sep 20, 2017

@Pauan

This comment has been minimized.

Show comment
Hide comment
@Pauan

Pauan Sep 20, 2017

Woah woah woah woah, PureScript is getting IO instead of Eff? When did this happen?

Pauan commented Sep 20, 2017

Woah woah woah woah, PureScript is getting IO instead of Eff? When did this happen?

@michaelficarra

This comment has been minimized.

Show comment
Hide comment
@michaelficarra

michaelficarra Sep 20, 2017

Contributor

@Pauan It was done via emoji-based Twitter poll — the most appropriate medium for language design discourse.

Contributor

michaelficarra commented Sep 20, 2017

@Pauan It was done via emoji-based Twitter poll — the most appropriate medium for language design discourse.

@Pauan

This comment has been minimized.

Show comment
Hide comment
@Pauan

Pauan Sep 20, 2017

@michaelficarra Thanks for the link.

That's great news! I always really liked the idea of Eff, but I hated the implementation:

  1. So many unintuitive errors for things which should work.

  2. Eff is always a 0-argument JS function, which means you can't have different implementations for different effects.

Pauan commented Sep 20, 2017

@michaelficarra Thanks for the link.

That's great news! I always really liked the idea of Eff, but I hated the implementation:

  1. So many unintuitive errors for things which should work.

  2. Eff is always a 0-argument JS function, which means you can't have different implementations for different effects.

@paf31

This comment has been minimized.

Show comment
Hide comment
@paf31

paf31 Sep 20, 2017

Member

Actually, it's been discussed in several other places before that, including on Slack, and on the eff repo, including an unmerged PR for a previous version. I think the eff repo is the right place to discuss it if there are objections, but this is the issue to track the necessary compiler changes. The Twitter poll was just one more check I wanted to do to see how the broader community (who might not watch all of the repos) might respond to the change.

Member

paf31 commented Sep 20, 2017

Actually, it's been discussed in several other places before that, including on Slack, and on the eff repo, including an unmerged PR for a previous version. I think the eff repo is the right place to discuss it if there are objections, but this is the issue to track the necessary compiler changes. The Twitter poll was just one more check I wanted to do to see how the broader community (who might not watch all of the repos) might respond to the change.

@garyb

This comment has been minimized.

Show comment
Hide comment
@garyb

garyb Sep 20, 2017

Member

Should we have a real issue about the name of Eff vs IO? I think a couple of threads on Slack about it means people's voices on it may be easy to miss. I was there for the first discussion that Phil wasn't, and it seemed like the consensus of having Eff :: Type -> Type was much preferable to renaming to IO, but then I saw the tail end of a Slack conversation the other day where the reverse seemed to be the case.

Member

garyb commented Sep 20, 2017

Should we have a real issue about the name of Eff vs IO? I think a couple of threads on Slack about it means people's voices on it may be easy to miss. I was there for the first discussion that Phil wasn't, and it seemed like the consensus of having Eff :: Type -> Type was much preferable to renaming to IO, but then I saw the tail end of a Slack conversation the other day where the reverse seemed to be the case.

@paf31

This comment has been minimized.

Show comment
Hide comment
@paf31

paf31 Sep 20, 2017

Member

Yes, sounds like a good idea.

Member

paf31 commented Sep 20, 2017

Yes, sounds like a good idea.

@spicydonuts

This comment has been minimized.

Show comment
Hide comment
@spicydonuts

spicydonuts Sep 20, 2017

I don't know much of the background on this, but Eff e a -> Eff a seems like a much better way to go if everything currently using Eff and Aff should be removing its effect rows. IO seems better if there's still a use case for keeping the current Eff implementation around (no idea what that would mean for Aff). I'd prefer modifying Eff and Aff in that case, because it basically keeps things working the way they are, just easier to work with. Converting to IO seems confusing from a dependency perspective (ex: pulling in 3 libraries and each use a different version of IO/Eff).

spicydonuts commented Sep 20, 2017

I don't know much of the background on this, but Eff e a -> Eff a seems like a much better way to go if everything currently using Eff and Aff should be removing its effect rows. IO seems better if there's still a use case for keeping the current Eff implementation around (no idea what that would mean for Aff). I'd prefer modifying Eff and Aff in that case, because it basically keeps things working the way they are, just easier to work with. Converting to IO seems confusing from a dependency perspective (ex: pulling in 3 libraries and each use a different version of IO/Eff).

@garyb

This comment has been minimized.

Show comment
Hide comment
@garyb

garyb Sep 22, 2017

Member

I'm slightly more in favour of keeping the Eff name and dropping the row than renaming to IO too. I could get used to it either way, but it definitely seems like the update overhead will be lower by continuing with Eff / Aff.

Member

garyb commented Sep 22, 2017

I'm slightly more in favour of keeping the Eff name and dropping the row than renaming to IO too. I could get used to it either way, but it definitely seems like the update overhead will be lower by continuing with Eff / Aff.

@hdgarrood

This comment has been minimized.

Show comment
Hide comment
@hdgarrood

hdgarrood Sep 22, 2017

Contributor

Let’s discuss what we call it in purescript-deprecated/purescript-eff#25 perhaps?

Contributor

hdgarrood commented Sep 22, 2017

Let’s discuss what we call it in purescript-deprecated/purescript-eff#25 perhaps?

@garyb

This comment has been minimized.

Show comment
Hide comment
@garyb

garyb Sep 22, 2017

Member

Sure, I'll port the comments over.

Member

garyb commented Sep 22, 2017

Sure, I'll port the comments over.

@starper

This comment has been minimized.

Show comment
Hide comment
@starper

starper Sep 22, 2017

+1 for having base IO a and Eff e a as an extended version of IO a

starper commented Sep 22, 2017

+1 for having base IO a and Eff e a as an extended version of IO a

@felixSchl felixSchl referenced this issue Sep 22, 2017

Open

WIP: Implement hooks #52

4 of 6 tasks complete
@Risto-Stevcev

This comment has been minimized.

Show comment
Hide comment
@Risto-Stevcev

Risto-Stevcev Oct 16, 2017

Now that Eff is being replaced, what do you guys think of bringing back the restriction that rows can't have duplicate labels?

Risto-Stevcev commented Oct 16, 2017

Now that Eff is being replaced, what do you guys think of bringing back the restriction that rows can't have duplicate labels?

@natefaubion

This comment has been minimized.

Show comment
Hide comment
@natefaubion

natefaubion Oct 16, 2017

Contributor

Purescript-run wouldn’t be possible without duplicate labels.

Contributor

natefaubion commented Oct 16, 2017

Purescript-run wouldn’t be possible without duplicate labels.

@paf31

This comment has been minimized.

Show comment
Hide comment
@paf31

paf31 Oct 16, 2017

Member

I think duplicate labels are a better, more principled choice for other reasons.

Member

paf31 commented Oct 16, 2017

I think duplicate labels are a better, more principled choice for other reasons.

@urs-of-the-backwoods

This comment has been minimized.

Show comment
Hide comment
@urs-of-the-backwoods

urs-of-the-backwoods Dec 7, 2017

I'm absolutely looking forward to this. Trying to write callbacks in React and stumble on Effects proliferation, since they spread upwards AND downwards, something I just learned, please go ahead! I have no substantial opinion on naming, but Eff/Aff seems ok, Aff is cool :-)

urs-of-the-backwoods commented Dec 7, 2017

I'm absolutely looking forward to this. Trying to write callbacks in React and stumble on Effects proliferation, since they spread upwards AND downwards, something I just learned, please go ahead! I have no substantial opinion on naming, but Eff/Aff seems ok, Aff is cool :-)

@darkf

This comment has been minimized.

Show comment
Hide comment
@darkf

darkf Feb 10, 2018

To clarify, does this mean PureScript will no longer have extensible / algebraic effects in favor of a Haskell-style IO a monad? If so -- Who in the world thought this was a good idea? This is one of the only reasons I use PureScript over transpiling Haskell. 😕

darkf commented Feb 10, 2018

To clarify, does this mean PureScript will no longer have extensible / algebraic effects in favor of a Haskell-style IO a monad? If so -- Who in the world thought this was a good idea? This is one of the only reasons I use PureScript over transpiling Haskell. 😕

@kRITZCREEK

This comment has been minimized.

Show comment
Hide comment
@kRITZCREEK

kRITZCREEK Feb 10, 2018

Member

@darkf PureScript will still have algebraic effects in the purescript-run library. Our current Eff implementation does not allow you to specify interpreters for effects, the effect row is purely a phantom type and does not allow introspection.

Member

kRITZCREEK commented Feb 10, 2018

@darkf PureScript will still have algebraic effects in the purescript-run library. Our current Eff implementation does not allow you to specify interpreters for effects, the effect row is purely a phantom type and does not allow introspection.

@darkf

This comment has been minimized.

Show comment
Hide comment
@darkf

darkf Feb 10, 2018

@kRITZCREEK Fair enough, but why not keep the phantom row type? It's rather useful to demarcate effects, even if it's not entirely safe. I'll take a look at purescript-run (but is it going to mesh well with third party libraries?)

darkf commented Feb 10, 2018

@kRITZCREEK Fair enough, but why not keep the phantom row type? It's rather useful to demarcate effects, even if it's not entirely safe. I'll take a look at purescript-run (but is it going to mesh well with third party libraries?)

@kRITZCREEK

This comment has been minimized.

Show comment
Hide comment
@kRITZCREEK

kRITZCREEK Feb 10, 2018

Member

@darkf Check purescript-deprecated/purescript-eff#25 and see if that answers your question.

EDIT:

My TLDR: Effect rows are useful and once you're accustomed to them you can track lots of relevant information using them, but they don't make for a good default. They are anti-modular in that you need a canonical location for an effect like DOM, they create boilerplate, and introduce a layer of complexity for beginners/intermediate users that provides little benefit in their small/medium sized projects.

Member

kRITZCREEK commented Feb 10, 2018

@darkf Check purescript-deprecated/purescript-eff#25 and see if that answers your question.

EDIT:

My TLDR: Effect rows are useful and once you're accustomed to them you can track lots of relevant information using them, but they don't make for a good default. They are anti-modular in that you need a canonical location for an effect like DOM, they create boilerplate, and introduce a layer of complexity for beginners/intermediate users that provides little benefit in their small/medium sized projects.

@darkf

This comment has been minimized.

Show comment
Hide comment
@darkf

darkf Feb 10, 2018

@kRITZCREEK Thanks for the summary. I see the point now, but I still philosophically disagree with an all-encompassing IO monad... As a beginner (at least coming from Haskell) I found Eff easy to use and nicer than IO, and it lets me read (and write) what categories effects certain code will use.

Will Purescript retain a tagged Eff monad, or will it be left to packages like purescript-run? (I'm not sure if it's been decided yet, there was a lot of discussion on that issue.)

darkf commented Feb 10, 2018

@kRITZCREEK Thanks for the summary. I see the point now, but I still philosophically disagree with an all-encompassing IO monad... As a beginner (at least coming from Haskell) I found Eff easy to use and nicer than IO, and it lets me read (and write) what categories effects certain code will use.

Will Purescript retain a tagged Eff monad, or will it be left to packages like purescript-run? (I'm not sure if it's been decided yet, there was a lot of discussion on that issue.)

@kRITZCREEK

This comment has been minimized.

Show comment
Hide comment
@kRITZCREEK

kRITZCREEK Mar 27, 2018

Member

The optimizer changes for Effect are in. Eff continues to be optimized for now as well as the Eff based ST. We should also look into optimizing the new standalone ST, but hopefully we can do a better job than the current hacky Eff ST optimizations with that.

@hdgarrood I assume we'll also need an instance for Effect for psci? Would that go into the psci-support repo or into the compiler?

Member

kRITZCREEK commented Mar 27, 2018

The optimizer changes for Effect are in. Eff continues to be optimized for now as well as the Eff based ST. We should also look into optimizing the new standalone ST, but hopefully we can do a better job than the current hacky Eff ST optimizations with that.

@hdgarrood I assume we'll also need an instance for Effect for psci? Would that go into the psci-support repo or into the compiler?

@LiamGoodacre

This comment has been minimized.

Show comment
Hide comment
@garyb

This comment has been minimized.

Show comment
Hide comment
@garyb

garyb Apr 24, 2018

Member

🎉

Member

garyb commented Apr 24, 2018

🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment