@@ -6,11 +6,43 @@
66-- Stability : experimental
77-- Portability : GHC
88--
9−-- Eval a fold asynchronously in a separate thread.
9+-- Using 'parEval' a fold can be decoupled from the driver and evaluated
10+-- concurrently with the driver. The driver just pushes an element to the
11+-- fold's buffer and waits for async evaluation to finish.
1012--
11−-- Use multiple worker folds to fold a stream and collect the results using
12−-- another fold, combine using a monoid. The results can be collected
13−-- out-of-order or in-order.
13+-- Avoid scanning a stream using a concurrent fold. When scanning a stream
14+-- using a concurrent fold we need to keep in mind that the result of the scan
15+-- may be delayed because of the asynchronous execution. The results may not be
16+-- same as in the case of a synchronous fold.
17+--
18+-- Stages in a fold pipeline can be made concurrent using 'parEval'.
19+--
20+-- The 'demux' combinator can be made concurrent by using 'parEval' on the fold
21+-- returned by the fold-generating function. Thus, we can fold values for each
22+-- key in the input stream concurrently.
23+--
24+-- Similarly, we can use 'parEval' with other cobminators like 'toMap',
25+-- 'demuxToMap', 'classify', 'tee', 'distribute', 'partition' etc. Basically,
26+-- any combinator that composes multiple folds or multiple instances of a fold
27+-- is a good candidate for running folds concurrently.
28+
29+-- TODO:
30+--
31+-- Before a fold returns "done" it has to drain the child folds. For example,
32+-- consider a "take" operation on a `parEval` fold, the take would return as
33+-- soon as it has taken required number of elements irrespective of whether the
34+-- child fold has yet finished or not.
35+--
36+-- parLmapM on a fold.
37+--
38+-- Use multiple worker folds to fold serial chunks of a stream and collect the
39+-- results using another fold, combine using a monoid. The results can be
40+-- collected out-of-order or in-order. This would be easier if each input
41+-- element is a streamable chunk and each fold consumes one at a time. This is
42+-- like parConcatMap in streams. We also need to have a lconcatMap to expand
43+-- the chunks in the input to streams before folding. This will require an
44+-- input Skip constructor. In fact, parLmapM would be implemented in terms of
45+-- this like in streams.
1446--
1547-- Concurrent append: if one fold's buffer becomes full then use the next one
1648-- Concurrent interleave/partition: Round robin to n folds.