Dear Russ,
As I understand you question, you want to have something similar to
Prolog in Oz. The actual issue is then implicit search, not the
variables (as Raphael already pointed out in one of his first answers
to you): Prolog variable do their 'magic' because of the implicit
search.
a way to constrain variables to be non-data-flow and that will result
in an exception if an operation that requires a value is attempted
when the variable is undefined.
You could define a assert-function to ensure a variable is determined
with Value.isDet.
Best,
Torsten
On 22.10.2005, at 01:47, Russ Abbott wrote:
A Mozart window that showed all the threads, showed which are blocked,
and indicated where they are blocked would help enormously.
----------
The following two situations are very different.
1. A program that blocks on a call to X.get() where get() is known to
block.
2. A program that potentially blocks at virtually any statement if one
has made an error.
Claiming that the existence of the former in Java 1.5 shows that the
latter makes for easy programming is not, in my opinion, very
convincing.
-----------
Regarding whether variables should be data flow variables, I would
strongly recommend that Oz implement a way to constrain variables to
be non-data-flow and that will result in an exception if an operation
that requires a value is attempted when the variable is undefined. As
it now stands, that's not possible (as far as I know).
Basically, I'm asking for an operation that would constrain an Oz
variable to act like a Prolog variable. If Oz takes its role as a
platform for the explication of programming languages seriously,
here's an important programming language paradigm element that is
apparently impossible to define in Oz.
Did I get you with that argument? Is Oz really a platform for
illustrating various programming language features, or is it a
particular view of how programming languages should work? If it's the
former, then we shouldn't be arguing about whether data flow variables
and ubiquitous suspension are good or bad. Programmers should be able
to chose whether or not use that feature in their programs. Again,
I'm not talking about stateful variables. I'm talking about Prolog
variables. So please don't tell me that stateful variables already
give you this choice.
-- Russ
On 10/21/05, Raphael Collet <[EMAIL PROTECTED]> wrote:
Russ Abbott wrote:
> 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.
My opinion is just opposite :-p Having variables being dataflow as a
default means that declarative components automatically behave well
with
concurrency. In fact, if the boundaries of a component are variables,
it will behave correctly in the presence of concurrency. Most
languages
require you to rewrite your program if you want to make it a bit
concurrent!
... and ...
Oz was designed to be concurrent. And its designer made the right
choice: thread communication should be through dataflow variables.
Even the Java guys understand it now. The last release introduced
*futures*. A future is nothing else than a dataflow variable. Java's
futures have a method get() that silently blocks until the future is
bound.
_______________________________________________________________________
__________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
--
Torsten Anders
Sonic Arts Research Centre
Queen's University Belfast (UK)
www.torsten-anders.de
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
