Hi, all!
I was trying to sort Alex Gian's problem out with the following code:
declare
proc {FailNotFree X} if {IsFree X} then skip else fail end end
NewChoice = {Service.synchronous.newFun fun {$} Free in Free end}
CutChoice = {Service.synchronous.newProc proc {$ X} X = unit end}
Choice = o(fresh:FailNotFree new:NewChoice cut:CutChoice)
% Example usage:
declare
proc {Script X}
C = {Choice.new}
in
choice
X = a
{Choice.cut C}
[]
{Choice.fresh C}
X = b
end
end
{Browse {SearchAll Script}} % should yield [a] only
Much to my dismay, I found out that the above solution does not work because
SearchAll runs both alternatives (partially) concurrently, as in (extracted
form Search.oz):
proc {AllNR KF S W Or Os}
if {IsFree KF} then
case {Space.ask S}
of failed then Os=Or
[] succeeded then Os={W S}|Or
[] alternatives(N) then C={Space.clone S} Ot in
{Space.commit1 S 1} {Space.commit2 C 2 N} %% CONCURRENCY!
Os={AllNR KF S W Ot}
Ot={AllNR KF C W Or}
end
else Os=Or
end
end
Surely, everything would work as (I) expected, if e.g. the above code read
thus:
proc {AllNR KF S W Or Os}
if {IsFree KF} then
case {Space.ask S}
of failed then Os=Or
[] succeeded then Os={W S}|Or
[] alternatives(N) then C={Space.clone S} Ot in
{Space.commit1 S 1}
Os={AllNR KF S W Ot}
{Space.commit2 C 2 N} %% NOT ANYMORE!
Ot={AllNR KF C W Or}
end
else Os=Or
end
end
My question is: in the light of this, can the behaviour of SearchAll be
considered to contain a (slight) bug?
(By the way, Alex, if you use the following version of the SearchAll procedure:
fun {All P}
S={Space.new P}
in
{AllNR _ S Space.merge nil}
end
.. and run my example with:
{Browse {All Script}}
.. then you'll have what you want! Apart from having to implement a whole new
search engine ;o) I guess that is the most elegant solution you might have to
your problem.
Cheers,
Jorge.
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
