Hi!
4) I still don't understand why my use of the CurrIsNum variable worked
OK! After all, it belongs to the "current space", just like
"FoundWord", and there it is unbound. Different values can be bound to
it in the two choice branches, yet when it leaves the "choice", the
uncloned, "current space" has become bound (correctly). Filip says that
this is because "I'm not using it to simulate a 'cut'", but I'm afraid
you've lost me there...
If "CurrIsNum" was cloned inside the "choice" statement, how come the
binding made _inside_ the choice statement propagated back to the
"current space" correctly? Surely the "current space" should have
remained unbound?
Maybe the intentation is a bit confusing here. The choice creates a
clone, but you carry on with the clone "ever after" the choice statement
(i.e., the effects of the inside statements do not vanish with "end").
Think of "choice" as non-deterministic "if".
You can do e.g.
CurrIsNum=choice false [] true end
or equivalently
choice
CurrIsNum=false
[]
CurrIsNum=true
end
You'll see that CurrIsNumis bound in all consecutive statements. It's
just if the search "backtracks" too far, namely before the assignment
statement, CurrIsNumwill be unbound (from that space's point of view,
there has been no assignment to CurrIsWord yet).
The difference between CurrIsNum and the FoundWord cell is obvious.
CurrIsNum is assigned in the respective choice statements and used
thereafter, there is no problem - whichever way you go, you get the
expected value in "{Encode Rest WList CurrIsNum}". In the case of
{Assign FoundWord true}, everything is fine again, but it does not do
what you want it to. Whenever the program "backtracks" beyond "choice",
it also backtracks the value of FoundWord to what it was (i.e. false).
More precise explanation is that the engine "forgets" the current branch
(the one with @FoundWord==true) and re-starts from the "choice"
statement, now taking the second alternative with @FoundWord==false. And
to get things even worse, note that the two alternatives can even be
executed in parallel (concurrently), so there is IMHO really no "clean"
way of the "first" having effect on the "second". The possibly
concurrent execution of the choices is what makes Oz so cool :-)
Cheers,
Filip
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
