Is concurrent Alternative instance for Task|Future Monad lawful?

[safareli]

My initial intuition was that (as of ap = <*>) Alternative intance of Task|Future Monad should be something like this (from purescript-aff) and it should not be implemented using never and race. but today i came across briancavalier/creed#92 and there Alternative is implemented using never and or(aka race). After thinking for a while it looks lawful, only issue i see (which actually might not be an issue), is that with distributivity law x.ap(f.alt(g)) == x.ap(f).alt(x.ap(g))

• in left branch, function from either f or g will be called
• in right branch, function from both f or g will be called

But as function in g should be pure it might not be an issue? If that's an issue, then Maybe also has this same issue (which I think is not present in Haskell because of laziness)

possibly related issues:

• Expose non monadic version of Future fluture-js/Fluture#44
• Expose non monadic version of Task origamitower/folktale#52
• create ParEff newtype with instances up to Applicative (+ Alt, Alternative, Plus) purescript-contrib/purescript-aff#5
• if Type is Monad than ap from Applicative should be sequential? #179

[safareli]

@jdegoes @garyb you have been maintaining Purescript-Aff, maybe you have an answer

[jdegoes]

The Alternative instance of Task|Future must run the first, if it fails, run the second — in sequence.

The Alternative instance for a Parallel must run both, at the same time, and return the first one which succeeds.

[safareli]

@jdegoes yes, that was my initial intuition, but which law is reason for that?

[jdegoes]

The laws are here: https://en.wikibooks.org/wiki/Haskell/Alternative_and_MonadPlus

They don't look like they force these, but they look compatible with them. Good question though.