Re: prelude extension proposal

From: Wolfgang Lux <>
Date: Fri, 14 Oct 2005 14:33:46 +0200

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
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.


curry mailing list
Received on Fr Okt 14 2005 - 15:19:03 CEST

This archive was generated by hypermail 2.3.0 : Do Jun 20 2024 - 07:15:07 CEST