Haskell's Missing Concurrency Basics (2016)

I had some sympathy for this situation, until I saw that the concurrency was being specified via a function called `mapConcurrently`.

IMHO this is perfectly acceptable behaviour for a `map` function, since that name has gained the connotation that its purpose is to transform one 'collection' (Functor; whatever) into another, by pointwise, independent applications of the given function. Providing a function/action which breaks this independence (by writing to the same handle) breaks this implicit meaning. Heck, I'd consider it a code smell to combine interfering actions like this using a non-concurrent `map` function; I would prefer to define a separate function to make this distinction explicit, e.g.

    -- Like 'map', but function invocations may interfere with each other (you've been warned!)
    runAtOnce = map

When using `map` functions (which is a lot!) I subconsciously treat it as if it will be executed concurrently, in parallel, in any order. Consider that even an imperative languages like Javascript provide a separate `forEach` function, to prevent "abuses" of `map`. Even Emacs Lisp, not the most highly regarded language, provides separate `mapcar` and `mapc` functions for this reason.

With that said, I recognise that there's a problem here; but the problem seems to be 'mapping a self-interfering function'. If we try to make it non-interfering, we see that it's due to the use of a shared global value (`stdout`); another code smell! Whilst stdout is append-only, it's still mutable, so I'd try to remove this shared mutable state. Message passing is one alternative, where we can have each call/action explicitly take in the handle, then pass it along (either directly, or via some sort of "trampoline", like an MVar). This way we get the "concurrent from the outside, single-threaded on the inside" behaviour of actor systems like Erlang. In particular, it's easy to make sure the handle only get passed along when we're 'finished' with it (i.e. we've written a complete "block" of output).

> I just don't see how monadic IO is relevant to this issue

Monad is effectively Haskell's definition of time: `A >> B` means A followed by B, `B >> A` means B followed by A. Yet Monad can't express concurrency; for that we need something else (e.g. Arrow).

> putStrLn either acquires a lock or it doesn't

It's not that simple: there's no point aquiring a lock after the text has been written; or relinquishing a lock before it's been aquired. To specify what we want, we need some way to sequence actions, and that's exactly what Monad is, i.e. we want `putStrLn` to be:

    getLock >> writeTheString >> freeLock

Then we need to consider the sequencing that's going on in the middle, since we need the first character of our string (e.g. "foo") to appear before the second, and so on. Hence we actually get:

    getLock >> putChar 'f' >> putChar 'o' >> putChar 'o' >> putChar '\n' >> freeLock

Hence we need Monad (or at least the definition of >> for IO) to orchestrate a single sequence of actions. I find it a little unsatisfying that to orchestrate multiple sequences we might just defer to some complicated parts of the runtime system like "locks" and "threads", written in C :(

As an alternative, we might imagine an "execute concurrently" combinator like `` to complement `>>`, where `A B` evaluates non-deterministically to either `A >> B` or `B >> A`. Yet this isn't particularly good, since `(A >> B) (C >> D)` can only evaluate to either `A >> B >> C >> D` or `C >> D >> A >> B`; there's no possibility for traces like `A >> C >> B >> D`, so we lose a lot of the reason to use concurrency.

One way to fix this is to define another way of sequencing, e.g. `A ->> B`, which behaves like `A >> B`. We can then pick one of these, e.g. `->>`, to interact with ``, such that:

    (A ->> B)  (C ->> D)

will evalutate non-deterministically to:

    A >> (B  (C ->> D))

or:

    C >> ((A ->> B)  D)

With a setup like this, we can then reframe the problem with `putStrLn` by saying that `putStrLn "foo"` evaluates to:

    putChar 'f' ->> putChar 'o' ->> putChar 'o' ->> putChar '\n'

Whilst we want it to evaluate to:

    putChar 'f' >> putChar 'o' >> putChar 'o' >> putChar '\n'

From this perspective, the problem is absolutely about monadic IO :)

Can we implement `` with threads and `>>` with locks? Sure; but we can also think about these things in a "more Haskelly" way, with combinators, equational laws, etc.

I get what you're saying too. :) I think one reasonable semantics for monadic I/O is that it sequences effects in a single thread; and effects from other threads are part of the world-state, not part of the monadic context. Another reasonable semantics is what I think you're describing: monadic I/O in a multithreaded program should sequence effects across all the threads (e.g., mutexes on shared resources). It would be nice to have both options available -- maybe similar to how you can plug a strategy into Haskell's Control.Parallel.Strategies monad.

https://hackage.haskell.org/package/parallel-3.2.1.1/docs/Co...

Yes, correct. I wasn't clear enough.