Re: prelude extension proposal

From: Wolfgang Lux <>
Date: Fri, 14 Oct 2005 14:01:40 +0200

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(*),
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).

> We
> could maybe have some kind of injection in order to revive a suspended
> computation, but this is not yet covered even by an operational
> semantics and thus postponed.

Incidentally, this is covered by an operational semantics as it works
in MCC as you see when you try out the example. :-)


(*) Encapsulation cannot be flexible because that would mean the search
goal could instantiate (probably non-determinstically) non-local

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