On Mon, 21 Jul 2008 18:44:49 +0200 Aristotle Pagaltzis <pagaltzis@[...].de>  wrote: 

AP>  A lot of people have bugs relating to their use of `each` or
AP>  flip-flop operators too because they forget to exhaust the implicit
AP>  iterator before starting another loop, or they reset it (in the case
AP>  of `each`) accidentally. Instead of making the counts global, which
AP>  couples everything tightly, you should pass around first-class
AP>  iterators, eg. the closure approach David Nicol showed. That
AP>  encapsulates the decision logic in one place but makes the scope of
AP>  each iterator explicit, so that you donâ??t run into problems with
AP>  reusing or reset iterators where you did not expect it.

I just don't like creating extra iterator variables.  It feels
so... Java-ish :)

On Mon, 21 Jul 2008 18:50:27 +0200 Abigail <abigail@[...].be>  wrote: 

A>  So, how would you use every() to print each 5th and 6th member, and print
A>  it only once?

As you and others have shown, every(5) + every(6) and such (| too) would
work.  But again, it's not what I wanted to talk about, the issue is
that caller() doesn't give the character position or opcode.

A>  Oh, I thought you were arguing to add Every.pm to the core
A>  distribution, but now it seems you want to add every() as a new
A>  keyword.

I started with wondering if there's any chance to add Every.pm to the
core, and the answer has been a clear "no."  As a reason for inclusion
(but note I'm NOT arguing, just clarifying my reasoning), I mentioned
that calling it in a tight loop requires optimizations that are best
avoided at the compiler level; if that requires a new keyword and can't
be done with a module then that's what I mean.  I don't know the Perl
compiler well enough to give any opinion.

Ted