Add parallel execution

[GuillaumeDesforges]

• Use performP instead of perfom, so that it uses PKleisli

[dorranh]

Nice! I just had one question (see above)

[dorranh]

If I'm understanding things correctly, this would enable parallel interpretation for basically any of the funflow effects whose inputs are independent from upstream outputs. Is that a correct understanding, and if so, would it be possible to also provide an option for disabling this? I can imagine someone will want a way to opt out of parallel execution while debugging at some point. IMO having it enabled by default is a reasonable default though.

[GuillaumeDesforges]

If I'm understanding things correctly, this would enable parallel interpretation for basically any of the funflow effects whose inputs are independent from upstream outputs.

Any branching would be parrallel, i.e.

() >- A -> a >- B -> (b, c) >- D -> d
                   >- C ->

you would have B and C run in parallel once a has been returned.
@YPares will confirm/invalidate this statement.

would it be possible to also provide an option for disabling this?

Yes, it can be done (& (if parallelExecution then performP else perform) input).
This will require to put back a "config" argument to runFlow I guess.

IMO having it enabled by default is a reasonable default though.

Agreed

[GuillaumeDesforges]

Waiting for NixOS/nixpkgs#94930 to be merged, so that I can push the currently oprhan instance to upstream kernmantle.

[dorranh]

@GuillaumeDesforges, just took a look at NixOS/nixpkgs#94930 and saw that it is still open. If that doesn't get merged soon we can always include the patch in this repo as well then remove it once your patch gets merged upstream.

[GuillaumeDesforges]

Looks like it just got merged, I'll wait for it to reach Hydra before updating the haskell.nix sources

[dorranh]

For the record, I explored providing a flag to control whether perform or performP is used but ran into some annoying technical issues (runFlowWithConfig won't type check since the type of all of the core components gets inferred using the concrete type in the perform or performP signature, and the core generation can't be split out into a separate function since it needs to be wrapped in the bracketed call to withStore).

Merging this as-is for now since users can still control parallelism using the standard Control.Arrow building blocks.