Alex, Execution of a choice statement causes the current space being _cloned_, and alternatives are activated for _independent_ clones. The thing is that that cell you were trying to use as a guard belongs to the current space and is therefore cloned. Whatever you do to it inside an alternative has no effect on the original cell or any of its other clones.
Ch.12 concerns logic programming, especially its relational flavour. However, as far as I understand, you are trying to simulate Prolog's cut, which is an eminently _non-logic_ construct. Even though what you want is possible, you have to understand that Oz is so meant not to be like Prolog that there are some obstacles. First of all, one must realise that cut strongly relies on a property of Prolog's search engine: sequentiality. Unfortunately for your plans, Oz does not provide a purely sequential library SearchAll procedure. However, that can be easily accomplished if you read my first message "bug in Search? was Re: Scoping problem ..." GIVEN such a sequential SearchAll procedure, cut is straightforwardly simulated, it sufficing to ensure that the guard variable does not belong to the current space, which prevents it from being cloned. That is why I resorted to Service in my solution (same previous message), which helps establish communication between spaces. By means of the functions created there, a global variable is created for the choice points involving cut. Cheers, Jorge. P.S.: Please do not feel an ignorant. Although the Oz manual is great and surely the result of much competent effort, clear info on spaces is rather sparse. Currently, experience and hacking into oz source (don't you miss Search.oz) usually helps understand this all-important primitive. Quoting Alex Gian <[EMAIL PROTECTED]>: > Hi Filip > > Well, I read Ch.12 of the tutorial crefully, and Ch.9 of CTM again, and > although I now know a lot more, I am still none the wiser! (I assume > ch12 of the tutorial is a bit dated, and I could do with a clearer > explanation of computing spaces.) Still - I'm getting there... > > For instance, although I can accept your explanation that the assignment > to the "FoundWord" Cell is bactracked in the second "choice" branch > (instead of acting as a guard), I notice that my variable "CurrIsNum" > which has _exactly_ the same scoping seems to work fine, no matter which > "choice" branch it is bound in... Hm... > > > Hm, I see. If you only need that some solutions imply that some other > > should be discarded, think of using a "choice penalty" and SearchBest > > instead of SearchAll. > > [...] > > See what I mean? > > This is not a bad idea practically, but I was really looking for > something a little more... elegant (no offence meant :) ). Also will > your method cause solutions to be generated which are then discarded?? > I would prefer it if it's already known beforehand that the solution is > not acceptable, that the program doesn't generate it only to discard it > a bit later. I admit I haven't studied the SearchBest functionaliy yet. > > Cheers > > Alex > _________________________________________________________________________________ > 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
