[Haskell-cafe] Haskell-Cafe Digest, Vol 158, Issue 29

[Richard A. O'Keefe]

On 1/11/16 9:54 AM, Joachim Durchholz wrote:
>
> And you need to control memory coherence, i.e. you need to define what
> data goes together with what processes.

At this point I'm puzzled.  Languages like Occam, ZPL, and Co-Array
Fortran basically say NO! to memory coherence.  Of course you say
which data goes with what process.  If the data need to be available
in some other process, there is some sort of fairly explicit
communication.

> In an ideal world, the compiler would be smart enough to do that for you.
> I have been reading fantasies that FPLs with their immutable data
> structures are better suited for this kind of automation;

Memory coherence exists as an issue when data are replicated and
one of the copies gets mutated, so that the copies are now inconsistent.
With immutable data this cannot be a problem.

For what it's worth, the "Clean" programming language used to be
called "Concurrent Clean" because it was set up to run on a cluster
of Macintoshes.

> Without that, you'd code explicit multithreading, which means that
> communication does not look like memory access at all.

I believe my argument was that it *shouldn't* look like memory access.