Heterogeneous concurrent apply

[pepeiborra]

We want to use rule parallelism in ghcide, but our user rules have heterogeneous key and result types.

The Apply applicative is to Shake as the Concurrently applicative is to async.

For an example of the intended usage, see:

haskell/haskell-language-server@dfeb649

[ndmitchell]

Were you aware that just doing normal applicative operations in the Action monad already does them together? So if you do apply F <*> apply X it will evaluate F and X in parallel. With that, do we need this mechanism?

[pepeiborra]

Were you aware that just doing normal applicative operations in the Action monad already does them together? So if you do apply F <*> apply X it will evaluate F and X in parallel. With that, do we need this mechanism?

I was vaguely aware, I requested that feature but it wasn't clear when/how it works. Can you clarify whether F and G are evaluated in parallel in fmap f (apply F) <*> fmap g (apply G)?

Do we still need this? Maybe. Apply guarantees that the parallelism happens, so it can still be useful.

[ndmitchell]

Any combination of operations that doesn't use >>= or join is guaranteed to be run in parallel - so your example above is guaranteed. I think there is an advantage of having Apply which makes it explicit, but a disadvantage of having to use apply' when most things are conveniently wrapped in a well-typed Action - e.g. you can't use need with apply' without exposing the internal types behind files (not a good abstraction) or adding need' (two functions for everything, which isn't great).

Looking at the docs for Action they don't mention this behaviour, which is a bug in the docs.

[pepeiborra]

That seems too good to be true. Why do we need parallel if that's the case?

[ndmitchell]

parallel came first - I should probably add to the docs that it isn't necessary in many cases.

There are still useful cases for parallel though - if your Shake threads are doing meaningful work, or there are monadic dependencies in either branch, it can help. But it's use case is significantly diminished from when you didn't have applicative merging.

[pepeiborra]

In that case, all we need to do in ghcide is enable ApplicativeDo and sit back. Nice! I'll give it a go and revert to this PR

[pepeiborra]

haskell/haskell-language-server#1667 enables ApplicativeDo in ghcide and seems to do the trick (although I have not collected any evidence of parallelism).

Closing this PR as unneeded, since the applicative instance already does what we need and as you said apply' is not always convenient to use.

[ndmitchell]

Thanks, I've improved the docs.