I wrote:
> Hi Bernd!
>
>> That is true. But one of the sanity conditions of getSearchTree we
>> discussed in the aforementioned paper, is that encapsulation should
>> also
>> not be rigid. Having strong encapsulation like defined in that paper
>> essentially means that you should not be able to influence the layout
>> of
>> the search tree by the remaining computation. In this point of view,
>> encapsulated suspensions can never awake and thus resemble a failure.
>
> In fact, in that view encapsulation is neither rigid nor flexible(*),
> but
> it is simply an error to use a non-local variable (except for putting
> it
> into some data term that is returned from the encapsulated search).
Upon a second thought, I should correct myself. The only reasonable
alternative to a rigid evaluation of non-local variables with a
resumption
of encapsulated search (as done in MCC), is a hyper-rigid getSearchTree
primitive, which suspends until all free variables in its arguments are
instantiated. Otherwise, the result of my example would depend on the
order of evaluation in the conjuction
y =:= head (tail solns) & lim =:= S (S Z)
If evaluated from left to right this would fail because the non-local
variable lim is uninstantiated and if evaluated from right to left the
it would succeed and bind y to S Z because there no longer is a free
variable in the search goal.
Regards
Wolfgang
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Fr Okt 14 2005 - 15:19:03 CEST