apply to it perl6 GC, which wouldn't always free memory immediately, so it could eat 3_000_000 or more.
Parrot runs a DOD (Dead Object Detection) sweep whenever its memory pools fill up, so this is probably a far smaller problem than you suggest. (If there still isn't any space in the existing pools after a DOD, it malloc()s a new one.)
ok, I know, that 1..n will return an iterator in perl6, which is called only when new item needed. great.
what I want to ask - would map and grep return an iterators too?.. if it's true, then previous construct becames very memory efficient, like if I write
loop ( ... ; ... ; ... ) {...; next if ...; ...; say}
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.
I suggest that this laziness be confined only to places where it's specifically asked for:
my @e=grep { even() } :lazy 1..1024;-- Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker
Oceania has always been at war with Eastasia.
