Dataflow concurrency instead of generators

[Jason Orendorff]

On Thu, May 14, 2009 at 7:35 PM, David-Sarah Hopwood
<david-sarah at jacaranda.org> wrote:
>> For instance, suppose that you have dataflow concurrency, as supported
>> by Oz and by recent dataflow extensions for Ruby, Python, and Scala:
>>
>> <http://www.mozart-oz.org/documentation/tutorial/node8.html>
>> <http://github.com/larrytheliquid/dataflow/tree/master>
>> <http://pypi.python.org/pypi/dataflow/0.1.0>
>> <http://github.com/jboner/scala-dataflow/tree/master>
>>
>> Then the functionality of a generator can be implemented using a
>> process/thread that extends a list or queue constructed from
>> dataflow variables.

I think you are proposing a model in which threads cannot share
mutable state and cannot have side effects which other threads can
see.

Even the simplest generator use cases can't be implemented using
threads and dataflow variables in that kind of model.  To take a silly
example:

  function iter(arraylike) {
      for (var i = 0; i < arraylike.length; i++)
          yield arraylike[i];
  }

  for (elt in iter(document.getElementsByTagName("A")))
      ...

DOM NodeLists are mutable and so are the nodes being yielded.

I like the idea of going after the concurrency problem now.  I like
the idea of doing one language feature instead of two (concurrency and
generators).  Do you have a solution in mind for this kind of problem?

-j