Towards 1.0.0: Deprecate all the ZValidation operators implying "parallelisation" in their names

[guizmaii]

zio-prelude 1.0.0 roadmap: #1359

• &> deprecated in favour of *>
• <& deprecated in favour of <*
• <&> deprecated in favour of <*>
• toZIOParallelErrors deprecated in favour of toZIOAccumErrors
• zipParLeft deprecated in favour of zipLeft
• zipParRight deprecated in favour of zipRight
• zipPar deprecated in favour of zip
• zipWithPar deprecated in favour of zipWith

@ghostdogpr @kyri-petrou Actually we have this issue a bit everywhere in prelude code. These for example uses this Par naming too while it doesn't parallelize anything:

🤔

[sideeffffect]

Oh, I just now realize what your problem with the names was and what's going on.

I don't have a super strong opinion on this and don't want to block you if you do and know what you're doing.

But, I just realized that the names are not arbitrary. They're very intentionally chosen. The point of the *Par naming is that it combines two instances that the two are evaluated independently of each other. As in, the evaluation of one doesn't depend/wait on the result of the other.

Thus, the name Par fits very well. Not in the sense that they are executed in parallel (and thus we get the final answer faster), but in the sense of semantic parallelism. And so I'd be more inclined to keep the naming (likely used in other parts of the codebase).

[guizmaii]

@sideeffffect

Hey 🙂
Thanks for this detailed answer.
I'd like to discuss the following:

But, I just realized that the names are arbitrary. They're very intentionally chosen. The point of the *Par naming is that it combines two instances that the two are evaluated independently of each other. As in, the evaluation of one doesn't depend/wait on the result of the other.

Thus, the name Par fits very well. Not in the sense that they are executed in parallel (and thus we get the final answer faster), but in the sense of semantic parallelism. And so I'd be more inclined to keep the naming (likely used in other parts of the codebase).

I'm sorry but I don't know what "semantic parallelism" means.
To me, either it's parallel/concurrent or it's sequential.
If we look at the code of ZValidation::zipWithPar (which is what is used under most other operators):

It seems to me that this is sequential, pure code.
Where is the "semantic parallelism"? 🤔

@ghostdogpr @kyri-petrou Any opinion?

[ghostdogpr]

See https://typelevel.org/cats/typeclasses/parallel.html, it's meant to be "parallel composition". I agree it's a bit confusing at first but I got used to it so I don't have a strong opinion.

[guizmaii]

Yeah, I know this type of class, but I always thought this name was terrible.

It seems to me that the important word in this Cats doc is "accumulating":

This is because defining a Monad instance for data types like Validated would be inconsistent with its error-accumulating behaviour. In short, Monads describe dependent computations and Applicatives describe independent computations.

So we could maybe reflect this notion in the name. We have an "Accumulative Applicative" behaviour.

So maybe a better would be zipWithAccum or zipWithBoth? 🤔
Or it might be just implied that zipWith does accumulate because of the nature of ZValidated? (Which could be an issue if we want to provide operators that are not accumulating) 🤔

[sideeffffect]

I don't think it's about "accumulation". I think the point is independence. When I write "semantic parallelism" I think of independence. When A and B are composed in a semantically parallel and thus independent manner, the result of A is not used to compute the result of B.

I consider this an important and name-worthy property.

But maybe "Parallel" is not the best name. Could we think of others?

• Independent / Indep

I can't think of anything better that that, but maybe you'll find these links inspirational https://www.google.com/search?channel=fs&q=synonym+to+parallel https://www.google.com/search?channel=fs&q=synonym+to+independent

[guizmaii]

I don't think that independence is what matters in this computation. I can compute A and B independently and only give you back B (which could also be the result of *>), which means that the way things are computed is not what's the essential/meaningful part of this computation.
Independence is already expressed by Applicative, but it's not the only thing happening here. We have an "Applicative-like" behaviour with an additional behaviour on top: accumulation/reduction.

To me, what matters is the end result: what is this function giving me back? What is this function doing?
This end result is a composition/accumulation/reduction of the result of A and B, which necessarily implies that A and B have been computed previously. Because A and B are pure code, no side-effect, no IO, there's only one way to compute them: sequentially, the order having no importance (hence independence).

I'd like to suggest this alias +> to replace &>,
so that we'd have 3 kind of fish operators in the ZIO environment we could easily document:

• "Star fish operator", A *> B, being an alias for "sequential flatMap and only keep right"
• "Plus fish operator", A +> B, being an alias for "sequential flatMap, accumulate/reduce and only keep right"
• "Gold fish operator", A &> B, being an alias for "concurrent flatMap and only keep right"