David Hopwood wrote:
In the case of threads, the original version of Oz, Oz 1, created
threads implicitly.
After some time we saw that this was the wrong decision. For example,
it makes reasoning about termination much harder. Again and again, we
learned the lesson that making things explicit is the best solution:
state, threads, laziness, search.
Perhaps this conclusion should be extended to explicit waiting on
dataflow variables ;-)
I don't think so. Just the opposite: *not* explicitly waiting on
dataflow variables is
actually the more complicated thing, so *that's* what should be
explicit. Keeping
dataflow variables as they are now means that all programs are concurrency
ready: they will work in a concurrent environment without any changes.
Languages that are not concurrency ready should not be taken as the norm
(in my
view those languages are defective).
See <http://www.erights.org/talks/promises/paper/tgc05.pdf> for
motivation.
This paper makes a very reasonable argument against shared-state
concurrency,
but I don't see how it motivates making waiting on dataflow variables
explicit.
Can you explain?
Peter
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
