Emilio Jesús Gallego Arias wrote:
> As your example showed, current non-determinism in FLP doesn't
> preserve program semantics in simple cases like:
>
> coin = 0
> coin = 1
>
> let x = coin in (x,x)
> !=
> (coin,coin)
>
> [Note that Sloth indeed can spot such simple cases and fix them, but
> it doesn't work in general, with eta-expansion and so on.]
Sorry, I don't understand that remark. Curry uses call-time choice
which means that both expressions are not equal. I do not see what
Sloth can do about this. The only option to make both expressions
equal I see is using a run-time choice semantics. There may be good
arguments for run-time choice, but it looks difficult to me to
reconcile sharing with run-time choice.
> We dislike semantics where this is not preserved, so perpetuating this
> kind of behavior is not a path we'd like to follow,
Are you asking for a change of Curry's semantics to use run-time choice
instead of call-time choice?
Wolfgang
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Fr Mär 30 2007 - 13:23:50 CEST