Remove parallel errors from ZPure

[ghostdogpr]

I propose to remove parallel errors from ZPure for several reasons:

• They were initially introduced when the plan was to make Validation use ZPure, but this idea was abandoned when ZValidation was introduced
• They are broken since the implementation of foldM is lossy via the use of first: foldCauseM((cause: Cause[E]) => failure(cause.first), success). This means a wide range of operators (mapError, catchAll, etc) are only keeping the first error anyway.
• The usage of Cause being different from zio.Cause is confusing, as well as the term Par which evokes concurrency, removing it simplifies the signature of runAll.
• There was a bug for years with zipParLeft and zipParRight not accumulating errors correctly and nobody found it until now, which makes me think nobody uses these.

[guizmaii]

LGTM but @sideeffffect might have a different opinion

[kyri-petrou]

I think this change makes sense, not only for the reasons mentioned but also because as a user I found the *Par methods confusing given that they don't execute concurrently (and shouldn't given that ZPure is synchronous)

[guizmaii]

@kyri-petrou I agree this is bad naming. We need to find a solution as this Par naming is used a bit everywhere in zio-prelude

In my opinion, the example of These is representative of our issue.
These has methods named &> and zipPar, while the code of these methods is not parallelising anything.
The issue is that, unlike ZValidation (See #1433), we can't just replace the &> method with *> as *> already exists. Same for These#zipPar as These#zip already exists too.

Any idea, guys, on how we could fix that? 🤔

[sideeffffect]

What I find the crux of the issue is whether we can make foldM behave properly.

If yes, let's modify it to be lossless. Because these Par methods can be useful (and intuitively named, since they hint at semantic parallelism).

If not, let's remove it all.

So what is the case? :)

[ghostdogpr]

What I find the crux of the issue is whether we can make foldM behave properly.

If yes, let's modify it to be lossless. Because these Par methods can be useful (and intuitively named, since they hint at semantic parallelism).

If not, let's remove it all.

So what is the case? :)

I don't think it makes sense to fix foldM and others because their signature takes a single E. Changing it to a list is effectively turning then into the existing Cause variants. And we don't want to keep only those because they make the UX very bad for people who don't use parallel errors (which I assume is nearly all ZPure users, since no one noticed parallel errors were broken).

An alternative is to do cause.forEach(failure) but I think it breaks semantics because it would make operators like catchAll or catchSome run the passed ZPure program multiple times.

I'm personally not too bothered by the Par suffix (once you get used to it, it's fine and cats uses the same terminology), however I find the Cause usage very confusing as the operators mimic the ones with zio Cause but with a completely different behavior. Imagine if catchAll in ZIO was swallowing the Die errors. This is what happens here.

So, I think we should get rid of it 😄 And if someone really want to run multiple ZPure, they can use .either and do what they want with the result pretty easily.

[sideeffffect]

OK, if we can't make it 100 % correct and consistent, then we must remove it.

Are we still using Cause? Or can we remove it altogether now?

[ghostdogpr]

Are we still using Cause? Or can we remove it altogether now?

Removed it (replaced a few usages by ParSeq[Unit, A])

[sideeffffect]

Feel free to merge, thank you 🙏

[sideeffffect]

https://github.com/zio/zio-prelude/releases/tag/v1.0.0-RC36

[guizmaii]

My PoV on the "semantic parallelism" thing: #1433 (comment)