Re: [ANN] LuaJIT-2.0.0-beta3

[Sam Roberts <vieuxtech@...>]

On Mon, Mar 8, 2010 at 10:48 AM, Mike Pall <mikelu-1003@mike.de> 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
file.
]] -- http://www.lua.org/manual/5.1/manual.html#pdf-io.lines

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.

Cheers,
Sam