John Cowan wrote:
> David-Sarah Hopwood scripsit:
>
>> Then the functionality of a generator can be implemented using a
>> process/thread that extends a list or queue constructed from
>> dataflow variables.
>
> Quite so. How, if at all, do these dataflow variables differ from
> Prolog variables?
Prolog itself is a sequential language (although there have been
many concurrent extensions of it). Prolog supports logic variables,
which are a generalisation of single-assignment variables that use
a unification algorithm for update. Dataflow variables are generalised
from single-assignment variables in a different direction, in order to
support sychronization between concurrent threads or lightweight
processes.
(view in fixed-width font)
single-assignment + unification logic
variables ---------------> variables
| |
| + concurrency | + concurrency
| |
v + unification v
dataflow variables ---------------> concurrent logic
variables
Historically (and at the risk of oversimplifying), the development
was from logic programming languages such as Prolog, to concurrent
logic languages such as Flat Concurrent Prolog, and later to
concurrent constraint languages such as AKL and Oz. Dataflow
variables are a simplified version of concurrent logic variables
that do not support update by full unification, but do support
being bound more than once to identical values.
> As a less complex option, lambdas + Lua-style semicoroutines.
Why do you say that the option I've suggested is complex?
Anecdotal evidence from programmers with experience of Oz and
other languages supporting dataflow concurrency suggests that
this programming model is typically found to be quite simple to
use. Certainly it is not complicated to specify or implement.
> These are
> first-class and deep; you can yield at any point, not just lexically
> within the coroutine, but don't support resuming arbitrary coroutines,
> only the caller (but it's easy to write a general coroutine dispatcher).
> Lua also provides multiple value returns for both coroutines and
> functions, but currently has no support for native threads.
I don't agree that coroutines are less complex than dataflow
concurrency. In fact, coroutines present almost exactly the same
potential complexities in the programming model as threading with
shared memory (which is significantly more complex than dataflow
concurrency), but without the performance advantage of being able
to support actual parallel execution.
--
David-Sarah Hopwood ⚥
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
