Brent 'Dax' Royal-Gordon writes:
> As you mentioned below, this causes problems if the code in question has
> side effects. But there are other cases where it messes up:
>
> sub even($_ = $CALLER::_) { ! $_ % 2 }
> my @e=grep { even() } 1..1024;
> #Okay, we don't need &even anymore...
> undef &even;
> say "@e";
>
> Put that C<undef> in an C<eval>, and all of a sudden you can't tell if
> the laziness is safe even at compile time.
Perhaps this isn't a problem. Think of your code this way:
my $even = sub ($_ = $CALLER::_) { ! $_ % 2 };
my @e = grep { $even() } 1..1024;
undef $even;
say "@e";
Is it a problem now? Nope. @e holds a reference to the grep generator,
which holds a reference to the code, which holds a reference to $even.
So the C<undef $even> didn't change a thing.
So it is only a problem if sub calls are made by name lookup as they are
in Perl 5. If the sub is predeclared, the call to even() my have been
made into a reference.
>
> I suggest that this laziness be confined only to places where it's
> specifically asked for:
>
> my @e=grep { even() } :lazy 1..1024;
There's a way to go the other way, to specifically mark it as non-lazy:
my @e = **grep { even() } 1..1024;
I don't mind lazy by default, as long as the error messages are smart
enough to know that they were inside a lazy generator. That is, in your
case:
Subroutine call to even() not defined at test.pl line 2
Called from lazy generator on test.pl line 2.
Luke
