The most embarrassing fact about Nobu's solution is its all in Pickaxe
http://www.rubycentral.com/pickaxe/tut_expressions.html :)

Exactly what happens is described in this quote: "You can use a Ruby range
as a boolean expression. A range such as exp1..exp2 will evaluate
as false until exp1 becomes true. The range will then evaluate
as true until exp2 becomes true. Once this happens, the range resets,
ready to fire again".

So exp1 (first=true) evaluates to true, then interpreter evaluates
boolean range
to true and waits until exp2 (false) becomes true which will never happen,
but on all consequent runs "and first" will guard "if" body from executing
(because exp1 is not executed anymore "first" gives you nil,
AFAIK what happens here is that "first" becomes "defined" name for the
interpreter
after first assignment but I can't say I have good grasp on this
"scoping" feature).

The problem with Nobu's solution obviously is inverse to mine (not working with
"for" loops).

Re Robert Klemme: as I said before this example is contrived, think about
cases where you don't how many iteration there will be until you start
iterating.

Enumerable#each_with_index is cool, and you get it for free by defining "each"
method on your class, but in my real-world case iterator isn't called each.

Re Jean-Francois Tran: seems like boolean range is completely
different beast from
Range object

Re Lloyd Linklater: I don't remember when was the last time when I was
battling CPU
time issues (IO, DB - there are plenty of), moreover check for the boolean flag
should be lightning fast (at least in ideal world :) ).
So it just seems "nice and clean" to me to keep all stuff (table
generating in this case)
in one continuous block.

Re list. rb: now that's refreshing :)