Re: Signature of iterator factories

[Jerome Vuarand <jerome.vuarand@...>]

2009/11/2 Jim Pryor <lists+lua@jimpryor.net>:
> At this point, I'm sure too much code would break to introduce any
> changes. But if we were designing iterators from scratch,
> wouldn't it be nice to give them this signature instead:
>
>    generator(control_variable, state_var1, ...)

That would only break iterators with a "generator" function (I don't
like the name) also usable as-is *and* interpreting extra arguments
(next wouldn't be impacted for example). Also it would be possible to
fix the problem "on site" with a wrapper function that force old
behaviour:

local function fix(generator, ...)
    return function(control_variable, state_var1, ...)
        return generator(control_variable, state_var1)
    end, ...
end

for k,v in fix(olditerator(t)) do end

So even though I don't feel the change as necessary (for the reasons
you gave), a change in the language would imho have minor impact.

> That way, we could pass multiple state_vars when we need to. I know,
> just pack all your state information into a table, or have your
> generator be a closure with the extra state information as upvalues.
> Easy enough to program. But it's a shame to bring in that overhead just
> because we can't write iterators taking more than one state_var.
>
> I don't know the VM architecture, maybe there are low-level reasons for doing
> it the way it is.

An argument (kinda weak I admit) against using more than one state
variable, is that the for construct only check the first iteration
variable when deciding whether to stop the iteration or continue it.
So you having more than one state variable may be confusing since they
are ignored by the construct itself.