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).
> 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. :-)
Regards
Wolfgang
(*) Encapsulation cannot be flexible because that would mean the search
goal could instantiate (probably non-determinstically) non-local
variables.
_______________________________________________
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