[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Signature of iterator factories
- From: Jerome Vuarand <jerome.vuarand@...>
- Date: Tue, 3 Nov 2009 12:23:58 +0100
2009/11/2 Jim Pryor <firstname.lastname@example.org>:
> 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
local function fix(generator, ...)
return function(control_variable, state_var1, ...)
return generator(control_variable, state_var1)
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.