Luke Palmer wrote:
>There are two reasons I've posted to perl6-language this time. First
>of all, is this acceptable behavior? Is it okay to die before the
>arguments to an undefined sub are evaluated?
>
>
>
Something like:
widgetMethod new Widget;
The best argument I've got for forcing the args to define is that
AUTOfoo might define them for you. I'm not sure that a similar argument
involving a possible AUTObar might not invalidate it, though -- is there
a type-based or virtual AUTOfoo behavior?
>Second, consider this "is lazy" code:
>
> sub foo ($bar is lazy) {
> my $bref = \$bar;
> do_something($bref);
> }
> foo(42);
>
>This will evaluate $bar, even if it is not used in do_something.
>
Okay, why? I'd expect the reference-taking to come nowhere close to
evaluating $bar, and passing $bref either passes the reference (no
evaluation) or looks at the reference, realizes that it's basically
"lazy, too", and punts.
>In fact, this will evaluate $bar even if the do_something call is omitted
>altogether. This doesn't give you much control over the time of
>evaluation, and presumably if you're saying "is lazy", control is
>precisely what you want.
>
>
I don't think control so much as aversion. "is lazy" means don't
evaluate this if you can avoid evaluating this.
>I think we need more control. I think "is lazy" parameters should
>pass a thunk that needs to be call()ed:
>
> sub foo ($bar is lazy) {
> say $bar; # says something like Thunk(...)
> say $bar(); # evaluates parameter and prints it
> say $bar; # still says something like Thunk(...)
> say $bar(); # doesn't evaluate again, just fetches
> }
>
>Whaddaya think?
>
>
>
Erm, no. I think "is lazy" describes $bar, and that means I use $bar as
'$bar' and perl dances madly to avoid evaluating it.
Suppose for a moment that there were levels of laziness -- there aren't,
but just suppose:
$x is lazy('Network IO involved. Create temporary variables and/or
closures to avoid losing this value once evaluated.');
$y is lazy('Horribly costly. Perform algebraic substitution before
evaluating this.');
$z is lazy('Possibly infinitely expensive. Only evaluate if halting
problem solved.');
The syntax of the language shouldn't change here. If I say "print $x"
then I'm telling you that I want to pay the price. It's a debug
statement or whatever, but I want those MIPS to get burned right now.
There's not much other way around it. (Of course, if the lazy entity is
a sequence it might be legitimate to print [sequence starting 1, 2, 3
...] instead of all possibly-infinitely-many values.)
Adding "is lazy" shouldn't change the code below it. It should just
speed it up where possible.
I like the idea of $x.value being a thunk, so that math or what-not
could actually be carried as an expression.
So that:
sub foo($bar is rw is lazy)
{
$bar++;
}
Becomes
...{
$bar.value = \{ my &v = $bar.value; postfix:++(&v());};
}
But $x.toString(), unless otherwise overridden, needs to keep
dereferencing ...value.value.value until some kind of basic type falls out.
Perhaps you could enumerate the various aspects of "value"? Obviously
there's value() and toString() (or whatever it's called.) How many such
are there?
=Austin
