Dear Russ,
A well-defined version of a generalised Append can still be called like
a deterministic function with two determined arguments and immediately
returns a solution -- without any search and without a solver call
(note that this definition of Append does not introduce any choice
points).
proc {Append X Y Z}
or X=nil Y=Z
[] Xs Zs Aux in
X=Aux|Xs Z=Aux|Zs {Append Xs Y Zs}
end
end
{Append [1 2 3] [a b]}
Now, if the programmer wants to use this Append in a search problem, an
explicit call to some solver is required. This approach allows to
control exactly which parts of the program perform a search and which
don't.
{SearchAll proc {$ Sol} X in choice X=[1] [] X=[2] end Sol={Append X
[a b]} end}
Best,
Torsten
BTW: Oz is a research project and not a commercial product. You are
most welcome to contribute to the development of the language or its
IDE (e.g. to write a Eclipse plugin).
On 18.10.2005, at 18:08, Russ Abbott wrote:
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
--
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
