Not being familiar with E, I'm guessing that it has the concept of
Futures, but not the full ability of dataflow variables. Hopefully not
to be too pedantic, but futures capture part of, but not all of the
essence of dataflow variables. Specifically, futures does not encompass
the unification of Oz's dataflow variables. Oz allows you to get
concurrency of futures and unification which manipulates futures without
having to write a different set of code depending on whether you want
sequential, concurrent, or logic based functions. Although the question
of blocking may be a stumbling block to understanding Oz, unification
implicit within Oz can also be mind altering. After all, a list
statement such as:
X = Y|Z
is going to blow the imperative mindset when one realizes that X may or
may not be assigned a value here. - If X, Y and Z are known, no values
will be assigned at all, but a unification error may occur if the
statement does not hold true for the values of X, Y and Z.
- If Y and Z are known, and X is not, then X will be assigned the value
Y|Z.
- If X and Z are known, then Y will be assigned a value
- If X is known but neither Y or Z is known, then a constraint is placed
in the store which will be used for verification when code later tries
to do an assignment.
- If X, Y, and Z are unknown, then the constraint is simply stored off
for future processing.
There's other patterns that are possible, but these are off the top of
my head. IIRC, CTM covers all the bases in one of the chapters.
Anyhow, futures can be used to get a lot of the effect, but there is a
bit of manual processing that has to go on to get unification to work.
The advantage of Oz is that a function can be written in such a way as
to be automatically concurrent and logic enable. You don't have to have
one function written without futures for non-concurrent processing and
one written with futures to get concurrency (dataflow processing makes
the code equivalent).
Thanks,
Chris Rathman
David Hopwood wrote:
Russ Abbott wrote:
CTM has a nice section on that on p 48.
- C++ uses whatever garbage was there.
- Java initializes variables in objects to some default value.
- Prolog issues an error message.
- The Java compiler refuses to compile such variables when they are
local (as in your example).
- Oz suspends silently and waits until the variable gets a value.
CTM lists these options in this order, which it considers increasingly
admirable.
I think it would be a very nice feature to be able to declare
variables to
be data flow variables. But for every variable to be treated this way is
quite unintuitive--especially for new Oz programmers.
In some other languages with dataflow variables, they have to be
declared.
For example in E (www.erights.org), "def x" declares a dataflow variable,
while "var x" declares a mutable variable. The latter is equivalent to a
variable associated with a first-class mutable "slot" or cell; E's kernel
language is similar to Oz in that respect.
This allows use of "var" variables that are not guaranteed initialized
to be a compile-time error, while not making it any more difficult to use
dataflow variables.
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
