lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Mon, Mar 8, 2010 at 10:48 AM, Mike Pall <> wrote:
> Peter Cawley wrote:
>> The change was regarding the standard io.lines function - I
>> read the manual as saying that io.lines returns an iterator function,
>> which just happens to work in the generic for loop, which is how the
>> standard implementation works. The LuaJIT implementation of io.lines
>> returns an iterator function and an iterator state, which again just
>> happens to work in the generic for loop, but doesn't work with code
>> expecting just a single function return value.
> Yes, someone else noticed this, too. My take on this is that it's
> up to the implementation whether an iterator factory (such as
> io.lines()) only returns an iterator function or an iterator state
> and/or an initial value, too. The pseudo-code given in the Lua
> manual for the iteration construct adjusts it to three results.

> So, if you're dropping the iterator state, you're relying on
> implementation-defined behavior. That logic would apply equally to
> all iterator factories.
> Maybe the Lua manual is in need of a clarification and/or it
> shouldn't specify how many results individual iterator factories
> (pairs, string.gmatch etc.) actually return (as this might change
> in the future).

Your point that maybe the manual should just describe functions as
being "iterator compatible" (so, returning up to 3 values) is
reasonable, however the lua 5.1 manual does explicitly state the
return value is a single function that can be called repeatedly:

Opens the given file name in read mode and returns an iterator
function that, each time it is called, returns a new line from the
]] --

I've iterated two files in parallel, in which case the generic for
doesn't work, so I don't think explicitly calling iterator functions
is unusual.