Sorry for all the messages.
My suggestion that 'choice' should mean that many threads are generated would eliminate the problem of using a non-deterministically defined Append deterministically outside SearchAll. When Append is used deterministically, only one thread will succeed. So there will be no problem.
-- Russ
On 10/20/05, Russ Abbott <[EMAIL PROTECTED]> wrote:
I'm surprised at how difficult it seems to be to get my point across. A new Oz user faces two problems.The first problem is simply to understand that Oz is *built to suspend.* That's not the sort of behavior that people expect when approach a programming language. Most programming languages are not built with silent suspension as such a major feature. That's why I think it is important to emphasize that basic fact and to make it as visible as possible for new users.Certainly, that information is available. But in my opinion it is not stressed enough. As far as I know, the documentation doesn't highlight silent suspension as fundamental to Oz. It is mentioned here and there as one of a number of Oz features. But in my opinion, silent suspension is different. It is one of the most basic principles of Oz semantics. It is not just a feature of Oz behavior in specific cases. It is part of what someone in an earlier messages called "the Oz way" which is to understand that Oz is defined as a language for writing programs in which threads will depend on each other--and that part of the language is to define conditions under which a thread will suspend in anticipation of being re-awakened by another thread. I'm not an expert on the history of programming languages, but is there any other language in which a thread suspends without an explicit statement in the language that causes the suspension?The second problem is to learn what the conditions are under which Oz suspends. Of course most people on this list know them. New users don't. For example:
- I didn't know that the Oz case statement suspends instead of doing unification if not enough information is available for pattern matching.
- I also didn't know that Oz suspends (but not immediately) when one attempts to unify with a variable outside one's computational space.
- Even knowing that Oz suspends when it encounters a choice statement, one doesn't always keep track of which procs contain choice statements. As I indicated, when moving a call to a non-deterministic Append from inside a SearchAll to outside Oz suspended. Intuitively it seemed reasonable to make that move since the particular use being made of the Append was deterministic. Most new Oz users aren't aware that they have to keep track of whether a particular implementation of a proc will work inside and outside of a SearchAll. Usually all one has to remember about a subprogram is its functionality, not its implementation.
Those and other cases illustrate the kinds of problems that a new Oz programmer faces. It doesn't help to say that if you know where the bugs are in your program it's easy to fix them. Of course that's true, but that kind of response trivializes the real problems that people encounter.It also doesn't help to say that if one has read all*the documentation and if one remembers it all, then one won't have those problems.Or should I understand by the responses I'm getting that I'm the only one who has ever encountered these kinds of problems?-- Russ
--On 10/20/05, David Hopwood < [EMAIL PROTECTED]> wrote:Christian Schulte wrote:
> I have to admit that I am also a little puzzled as to why Russ comes to the
> conclusion that thread suspension is somehow opaque. CTM gives much of the
> whole truth but as it comes to the more delicate issues that relate to
> search and spaces and stuff, there is a book providing a rather lengthy and
> full-fledged discussion of that (more than you ever want to know):
> http://web.it.kth.se/~schulte/paper.html?id=Schulte:LNAI:2002
And in any case, the conditions under which operations suspend are quite
intuitive, IMHO. They are just what you would expect from the principle that
operations should proceed whenever they do not need the value of an unbound
variable.
--
David Hopwood < [EMAIL PROTECTED]>
_________________________________________________________________________________
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/
--
_____________________________________________
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
