🚀 go-pugleaf

In article <8203@icot32.icot.or.jp> hawley@icot32.icot.or.jp (David John Hawley) writes:
>In article <CHIK.90Dec17194110@icot21.icot.or.jp> 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