Switch from Eff to IO

[paf31]

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

[Pauan]

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

[michaelficarra]

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

[Pauan]

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

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]

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]

Yes, sounds like a good idea.

[megamaddu]

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]

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]

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

[garyb]

Sure, I'll port the comments over.

[starper]

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

[Risto-Stevcev]

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

[natefaubion]

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

[paf31]

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

[urs-of-the-backwoods]

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]

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]

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

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

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

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

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]

It'd be added to this instance chain https://github.com/LiamGoodacre/purescript-psci-support/blob/59ebfb83097629530249bba267384857d90d9638/src/PSCI/Support.purs right?
(my 0.12 PR purescript/purescript-psci-support#7)

[garyb]

🎉