coordination lang's

8.8: bk.adda/concurrency/replace c`threads with c`coordination co.lang:

Another approach that puts more emphasis on the avoidance of deadlock
is promises, as realized for example by Mark Miller
in the E programming language .
These are also called futures,
and are originally attributable to Baker and Hewitt
Here, instead of blocking to access shared data,
programs proceed with a proxy of the data that they expect to eventually get,
using the proxy as if it were the data itself.

All of the above techniques prune away some of the nondeterminacy of threads.
However, they all still result in highly nondeterministic programs.
For applications with intrinsic nondeterminacy, such as servers,
concurrent database accesses, or competition for resources,
this is appropriate.
But achieving deterministic aims through nondeterministic means remains dif├×cult.
To achieve deterministic concurrent computation
requires approaching the problem differently.
Instead of starting with a highly nondeterministic mechanism like threads,
and relying on the programmer to prune that nondeterminacy,
we should start with deterministic, composable mechanisms,
and introduce nondeterminism only where needed.

The message is clear. We should not replace established languages.
We should instead build on them.
However, building on them using only libraries is not satisfactory.
Libraries offer little structure, no enforcement of patterns,
and few composable properties.

I believe that the right answer is coordination languages.
Coordination languages do introduce new syntax,
but that syntax serves purposes that are orthogonal
to those of established programming languages.

8.11: Multiagent System Engineering: the Coordination Viewpoint

. from the perspective if this paper,
c.lang would be for describing the agent's individual tasks,
whereas the coordination.lang is describing the agents' social tasks .