Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!rutgers!usc!wuarchive!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!fauern!tumuc!guug!ecrc!micha From: micha@ecrc.de (Micha Meier) Newsgroups: comp.lang.prolog Subject: Re: co-routining Message-ID: <2593@ecrc.de> Date: 19 Dec 90 09:19:17 GMT References: <8203@icot32.icot.or.jp> Sender: news@ecrc.de Reply-To: micha@ecrc.de (Micha Meier) Distribution: comp Organization: European Computer-Industry Research Centre Lines: 62 In article <8203@icot32.icot.or.jp> hawley@icot32.icot.or.jp (David John Hawley) writes: >In article chikayama@icot.or.jp writes: >>What's wrong with "freeze"ing a goal which, in addition to calling the >>main "Goal", will traverse the data structure the variable is >>instantiated to, hooking up the same goal to all the variables in the >>structure on its way? For example: > >(context: SICStus Prolog) The problem with this is when you "unify >distinct variables occuring in Term" to each other. The only predicate >I know of that can capture such events is dif/2 (a sound implementation >of \==), but I can't see how to use it to do what the first author wants. >On the other hand freeze/2 waits for "instantiations", i.e. it doesn't >trap Var=Var. The problem is not only with binding a variable to another one, but also to delay a goal whose structure is not fixed, i.e. the variables to delay on have to be extracted from it at run-time. In my opinion, freeze/2 is not well suited for this. Although it can be used for that, the resulting program does not look neither declarative nor readable. In SEPIA it is possible to specify whether a goal is woken only by the instantiation of a variable or even by its binding, possibly to another variable. The delay condition is expressed using delay clauses in the form delay Pred if Condition. Condition has the form of a normal clause body, and it can contain the predicates var/1, nonground/1, \==/2 and user-defined external predicates. When var/1 and nonground/1 are used, the goal is woken only by instantiating the appropriate variable because the system knows that it would re-delay with a mere variable binding. When \==/2 is used, on the other hand, the goal is woken even by a variable binding. The choice of the predicates allowed in the body of a delay clause seems deliberate, but in fact it is not. Although we initially intended to allow any Prolog predicates in the body of a delay clause, we changed the design because this approach would imply serious semantic problems, namely mixing meta- and object-level computation. Since we wanted the delay clauses to be efficient, we decided to restrict the allowed conditions to these three, and it turned out that for most of the 'normal' applications, this is more than enough. For a more advanced usage, e.g. to implement constraints, it is much more difficult to isolate what conditions will be used, and that's why we allow the users to write their own conditions in C and add them as external predicates to Sepia. The user can in fact specify a very complex delay conditions, for example specify that the goal should delay when first called, unless it contains less than N variables, but whenever any of its variables is bound, it will be woken and it will continue, even if it has less than N variables. To anyone who is interested: the binary of SEPIA is available to universities for a nominal fee of ~$200 (for any number of machines) together with a graphical system for X and sunview and now also with the high-level debugging tool OPIUM. --Micha -- E-MAIL micha@ecrc.de MAIL Micha Meier ECRC, Arabellastr. 17 8000 Munich 81 Germany