The WaitNeeded stuff sounds very interesting.  I hadn't run across it before.  I now see that there is some documentation in 10.1 of the base environment as Kari pointed out and in CTM 13.1.13. So far, I haven't been able to develop an intuition about it.  Would you help me out with a simple example?
 
Suppose I want to write some code that looked like this.
 
local Y
 proc {DontSuspend X} ... end
in
 {Browse Y+1}
end
 
and I wanted that code to throw an exception instead of suspending.  What would I write in DontSuspend?  (Raph's example seems to require that I put my {Browse X+1} code into DontSuspend, which is somewhat different--although that seemed to suspend instead of throwing an exception anyway.)  As you can see, I need some help with this.
 
Thanks.
 
-- Russ


 
On 10/22/05, Raphael Collet <[EMAIL PROTECTED]> wrote:
Russ Abbott wrote:
> 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).

You're too dismissive.  It's pretty easy to write, in fact.  The idea is
to run some code when a thread needs the value of a variable.  That's
exactly how we have (re)defined lazy computations in Oz!

proc {DontSuspend X}
   thread
      {WaitNeeded X}
      if {Not {IsDet X}} then
         %% put your code here
      end
   end
end

If X={DontSuspend}, then you have to determine X before trying to use
it.  The statement {WaitNeeded X} blocks until some thread needs the
value of X.  The conditional after it is necessary because determined
variables are needed by convention (so "being needed" a monotonic property).

> 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.

We don't want to explain other languages in Oz.  That could not work.
We want to be able to show useful programming concepts, and those
concepts should be modular.  The behavior you ask for is not composable
with concurrency.  What you ask for is a debugging tool, IMHO.

Most of the designers of Oz know Prolog well.  They know its strengths
and weaknesses.  Oz was not designed to be the successor of Prolog.  It
was designed to be a general-purpose language.  Prolog's paradigm has
some restrictions that do not allow this generality.


Cheers,
raph

_________________________________________________________________________________
mozart-users mailing list                               [email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users



--
_____________________________________________
Professor, Computer Science
California State University, Los Angeles
o Check out my blog at http://russabbott.blogspot.com/
_________________________________________________________________________________
mozart-users mailing list                               
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users

Reply via email to