Problem with SyncLaws.repeatedAsyncEvaluationNotMemoized

[alexandru]

We have a problem with SyncLaws.repeatedAsyncEvaluationNotMemoized.

I have not payed attention and the law has been redefined to use *> instead of >> in PR #80.

This is a problem because *> has no ordering guarantees and according to the its definition, it can only work when product is defined in terms of flatMap.

This is not necessarily the case guys. Therefore my tests for my non-deterministic Task instances, the one that does parallel processing, are now failing in Monix.

Of course, this non-deterministic Applicative instance that needs to be imported in scope has always been a hack in search of a better solution.

But the law itself can only work if you have ordering imposed. No ordering means that there's a race condition for setting the var in question. And you don't have ordering without using flatMap. Hence *> usage is incorrect.

[djspiewak]

*> has ordering guarantees when the underlying F[_] also forms a monad. This is literally in the laws. While I've had some disagreements about whether or not it is appropriate to use *> when >> is semantically intended, it really is unambiguous that the two are equivalent when used on an F[_]: Monad.

I don't have any personal objections if you wish to rewrite the instances of *> to use flatMap instead, mostly because I don't feel this is a war worth fighting right now. :-) But to be clear, this is happening precisely because your Applicative[Task] instance violates the monad laws. It's just that the violation cannot be shown without effects, which is why you only see it in SyncLaws.

Think about it this way: if SyncLaws exhibits this failure, why would you think that client code would not?

[alexandru]

@djspiewak you're assuming a fight, aren't you? 😀

I had no idea that Monad now implies that *> is ordered. It is a change of contract that I haven't noticed, diverging from what we used to do, even back in Scalaz's Task.

I'm having a conversation on cats-effect with @SystemFw and @LukaJCB and this time I agree 😛that non-deterministic Task instance needs to go.