On Mon, Oct 06, 2008 at 09:16:27AM +0800, Xiao Yafeng wrote: : + : > +The function may choose to terminate its list by returning (). : > +Since this operator is list associative, an inner function may be : > +followed by a C<...> and another function to continue the list, : > +and so on. Hence, : > + : > + 1 ... { $_ + 1 if $_ < 10 } : > + ... { $_ + 10 if $_ < 100 } : > + ... { $_ + 100 if $_ < 1000 } : > + : > +produces : > + : > + 1,2,3,4,5,6,7,8,9, : > + 10,20,30,40,50,60,70,80,90, : > + 100,200,300,400,500,600,700,800,900 : > + : > =back : : : curious whether I can say: : 1... {$_ + 1 if @_.elems <10} : : 1,2,3,4,5,6,7,8,9,
Good question. I think it ought to be okay, though it basically forces the operator to keep track of the entire array in order to pass it in as a slurpy on every iteration. But it seems like *-ary args should be allowed as an extreme case. Here's the same thing more explicitly, expressed in unary form: @seq := 1 ... { $_ + 1 if @seq < 10 } The thing is, the operator will still have to keep track of all the values even if the list has already given away some of those value via an iterator. Here's a cute variant that doesn't have to store all the values just to keep count: 1 ... { $_ + 1 if ++(state $) < 10 } Hmm, I think *my* state's $ will soon be less than 10, at the rate they're spending... :) Larry