Hi Torsten,
Thanks for the interesting example.
I'll admit to being confused about the status of 'or'. It doesn't appear in CTM. The only reference to it in the Global Index is to Bool.'or'. Even that is misleading. It claims that Or always evaluates both arguments, but
declare X
{Browse {Or X == 0 true}}
{Browse {Or X == 0 true}}
suspends instead of returning true.
But more to the point. The 'or' control structure you mention is described in 12.5 of the tutorial. (http://www.mozart-oz.org/documentation/tutorial/node12.html#label72
). I couldn't find it anywhere else. From that description and the explanation in 12.7.1, I was able to see how it differed from 'choice' and 'dis' but not how 'choice' and 'dis' differed from each other.
Also, I don't understand the semantics of 'or' itself. When I run the following
local
proc {Append X Y Z}
or
Y=Z % Note: Y = Z done first. So Z = [d e f]
{Show a1#X#Y#Z} % Confirmed by the output line 1
X=nil
{Show a2#X#Y#Z}
[] Xs Zs H in
{Show b1#X#Y#Z} % But this shows Z is still uninstantiated (line 2)
X=H|Xs
Z=H|Zs
{Show b2#X#Y#Z} % This shows that Z = a | _
{Append Xs Y Zs}
end
end
A B
in
{Browse {Append [a b c] [d e f]}}
end
proc {Append X Y Z}
or
Y=Z % Note: Y = Z done first. So Z = [d e f]
{Show a1#X#Y#Z} % Confirmed by the output line 1
X=nil
{Show a2#X#Y#Z}
[] Xs Zs H in
{Show b1#X#Y#Z} % But this shows Z is still uninstantiated (line 2)
X=H|Xs
Z=H|Zs
{Show b2#X#Y#Z} % This shows that Z = a | _
{Append Xs Y Zs}
end
end
A B
in
{Browse {Append [a b c] [d e f]}}
end
I get this as the first three lines of output.
a1#[a b c]#[d e f]#[d e f]
b1#[a b c]#[d e f]#_<optimized>
b2#[a b c]#[d e f]#(a|_<optimized>)
...
Since 'or' does not create a choice point, how can Z have two different values?
If you run the same version of append inside SearchAll with only the 3rd argument instantiated, you get the wrong answer.
{Browse {SearchAll fun($) A B in {Append A B [a b c]} A#B end}}
produces [_]. (I don't understand what that means either.)
So I'm very confused about what 'or' does.
Thanks.
-- Russ
On 10/19/05, Torsten Anders <[EMAIL PROTECTED]> wrote:
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 wrotethe 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
> outsidethe 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 thatwork 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
> developmentOz 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 Mozartto 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
> therun-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
--
_____________________________________________
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
