Hi Sergio,
> There is an interaction between the order of evaluation and the
> run-time choice. Incidentally, "run-time" is a bad choice (sic!)
> of name, since the call-time choice occurs at run-time as well;
> better names are eager choice and lazy choice.
You are right, run-time choice is probably a bad name, I will
use eval-time choice henceforth. I don't think that eager and
lazy choice are good names because they are easily confounded
with eager and lazy evaluation. To make things worse, eager
choice matches what is commonly understood as lazy evaluation,
i.e., non-strict evaluation with sharing a.k.a. call-by-need.
> In your example "dbl", if you want the lazy choice, but evaluate
> (0 ? 1) a bit early, you will not get the value 1, hence you will
> not get the lazy choice.
Indeed, the interaction between call-time choice (sharing) and
eval-time choice (no sharing) is rather subtle. In my example
a compiler might notice that the body of dbl always evaluates
its argument and hence evaluate the argument eagerly before the
call. But then, the compiler must not evaluate an expression of
the form ({ e }) eagerly because this could introduce some
unintended sharing as shown by the example.
Problems like this are the reason why I'd prefer the restricted
proposal where eval-time choice is used only for specially marked
arguments of data constructors. In that case, both the function
which applies a data constructor and the function which matches
the data constructor know about the eval-time choice semantics.
Wolfgang
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Fr Aug 28 2009 - 09:41:42 CEST