Not to get into a language war, but having translated the first 8 chapters
of CTM into a language where the futures have to be explicitly declared, I
would confess that it would be much nicer if all variables would act like
dataflow variables. That way you don't have to come up with seperate algorithms
or redesign when the decision on concurrency and/or unification will effect
the code and the type signatures.
As for the behavior of uninitialized
variables, that can be puzzling the first couple of times you encounter it
- in Oz or any other language with futures. But once you understand why the
blocking occurs, you're well on your way to understanding dataflow variables.
And, as CTM makes clear, dataflow variables are the crux of the biscuit when
it comes to the Oz programming language. If you don't understand dataflow
variables, you won't get very far.
The problem with your example though
is that it makes the assumption that Oz is like any other run of the mill
imperative programming language. In fact, the uninitiated programmer is likely
to read the statement somewhat more like the following:
declare X={NewCell
0}
{Browse @X+1}
because the student is making the assumption that the
variable acts like variables in any other imperative programming language
that they've been exposed to. Oz made the choice to expose the power of
dataflow
variables as the default, and make programming using state something that
has to be explicitly declared (a philosophy it happens to share with the ML
family of languages). CTM makes the case that explicit state is a powerful
programming technique, but it comes with some costs - not necessarily evil
like a purist might maintain but it should be minimized as much as possible.
Anyhow, that'd be my take as one who has not written much Oz code but has
spent some time reverse engineering the examples in CTM.
I have been quite
interested in your experiences in that the two chapters that have given me
the most trouble are Chapters 9 and 12 - which happens to correspond to the
main focus of your course. From my perspective Chapter 9 is not hard to
understand,
but it is rather hard to translate to any other language (currently trying
to use CALL/CC without much luck). Chapter 12 has some correlaries in other
languages, but it's a subject that I am trying to get my head around - none
too successfully at the moment.
Perhaps what I really need to do is sign
up for your course!!! :-)
Thanks,
Chris Rathman
P.S.: You give me more
credit than I deserve in the Solver code. All the code comes from either
the book (in chapter 9) or from the Supplements page on the books web site.
Specifically the Solve routine can be found at:
http://www2.info.ucl.ac.be/people/PVR/ds/booksuppl.oz
I've gotten pretty good at reverse engineering Oz code but my ability to
write code in Oz would take a bit of practice - which is backwards from most
languages as I find writing code is usually easier then reading code. :-)
--- [EMAIL PROTECTED] wrote:
> If someone told you, "Try this neat
new language," and you typed in what
> seemed like the simplest of all programs::
>
> declare X
> print X+1
>
> and nothing at all happened. Wouldn't
you be confused? Perhaps you even
> intended to type:
>
> declare X =
5
> print X+1
>
> and just forgot the "= 5" part. Wouldn't you expect
the language to help you
> out and wonder why it didn't? No response at all
is what you get from a rude
> clerk when you don't ask for something in exactly
the right way.
> -- Russ
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
