Wolfgang Lux wrote:
> > Thus, in case of I/O-based programs, we could not be sure that we always
> > avoid runtime errors due to non-determinism. In my mind, this would be
> > a major drawback. The fact that we might not see a good example at the
>
> I agree that this is a problem (and in fact Rafa and I already have been
> trapped by that during our work on the debugger). But we have to face the
> fact that we cannot have both sharing and encapsulation of all
> non-determinism.
If this is the case (and it actually seems to be the case),
one has to decide what is more important: sharing or encapsulation?
As Frank already pointed out, there must be a possibility to
encapsulate all non-determinism in order to write reliable
interactive programs. Thus, if my option 3 is the only possibility
to do this, I am still in favor to commit to it, even we loose
sharing or, as you pointed out, the results depend on the evaluation
order. Note that this is in some sense already be the case:
if you change the order of defining equations (which does not change
the declarative meaning of a function), you obtain the answers
in a findall in a different order. This is due to the fact that
"try" is a meta-level construct which depend on the evaluation order
of the underlying program.
> Yes, and so would be a solution where trying to bind a non-local variable
> would not cause unexpected deadlocks in your program. However, the problem is
> the same in both cases; there is no sound way to do this.
It is unclear to me what do you mean by "sound"?
"Try" is related to the meta-level, so it might be difficult to
talk about soundness for "try".
Best regards,
Michael
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Di Jan 15 2002 - 07:42:34 CET