All that's fine. But when learning a language, a very standard approach is to look at the syntax and try out the defined constructs. If one does that, one will find that one of them (choice) is accepted by the compiler but (mysteriously) doesn't seem to do anything.
Instead of suspending silently, either the compiler or the run-time system should report a problem when choice is used outside a search. As you say, a warning would help.
My example shows that this is not just a problem for new users. There can be two versions of Append/3, a deterministic version in which only the third argument may be uninstantiated and the more general version in which any of the arguments may be uninstantiated. In my example, I used append as an argument to FoldR. I also used Append/3 elsewhere in the program. As an argument to FoldR, all I needed was the deterministic Append. Elsewhere in the program I needed the non-deterministic Append. The reference in all cases was therefore to the non-deterministic Append since it didn't matter.
Once I wrote the program and got it working, Append had become encapsulated in my mind and I was no longer thinking about how it was defined. This is a basic principle of abstraction. One shouldn't have to worry about implementation issues once a library procedure has been defined.
Then, a week later, I moved a reference to this encapsulated Append outside the search context--and the system mysteriously suspended. Of course, I eventually figured out what the problem was. But the point is that a reasonable development environment or a reasonable run-time system should have done that work for me.
In this case, for example, the development environment could have noticed that I was passing a proc that was defined with multiple output parameters to FoldR at a parameter position at which I should have passed a function. I realize that at this stage in its development Oz does not even require that sort of declaration. (The "?" is optional.) I also realize that Mozart isn't Eclipse, the Java IDE, which to my mind sets the standard for useful IDE's. But it would be useful for Mozart to move in that direction. A first step might be for the compiler to check paths outside search and issue an error/warning if a choice is reachable. An alternative would be for the run-time system to issue an error/warning if a choice is reached when executing outside a search. Either one of those would have saved me some time and frustration--and would have saved this list all these messages.
-- Russ
On 10/17/05, Raphael Collet <[EMAIL PROTECTED]> wrote:
Russ Abbott wrote:
> It is extraordinarily frustrating for Oz to suspend silently when it
> runs into a choice statement outside a search.
This behavior it is exactly what its semantics prescribes. Maybe a
warning in the program's output could help...
> because Append is defined using choice. I know there are other ways to
> write this to make it work. But my point is that this way should either
> work or some diagnostic should tell you that the program is
> ill-structured. One way to make it work is to launch an implicit
> SearchAll and raise an exception if you get more than one answer.
Implicit search is a mistake as well. You don't usually use stateful
data inside search, but state is all around in the "toplevel" space! Oz
programs are stateful concurrent, perform I/O, and the language is
distributed. Search simply cannot be considered in this situation.
Computations spaces provide exactly what a search process needs: the
program to be explored must be in a closed world, it cannot interact
with the "external" world.
> Alternatively, a way to produce a diagnostic is to trace paths outside
> the SearchAll and produce an error message if a path leads to a choice
> statement. As it is, it produces great frustration to make what seems
> to be an innocent program transformation and find that the resulting
> program seems to do nothing.
Such a program transformation is innocent only in Prolog. In Oz, this
is explicitly a programming model shift!
Never use "choice" unless you really intend to use search.
Cheers,
raph
_________________________________________________________________________________
mozart-users mailing list [email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
_________________________________________________________________________________ mozart-users mailing list [email protected] http://www.mozart-oz.org/mailman/listinfo/mozart-users
