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