Re: Signature of iterator factories

[Jim Pryor <lists+lua@...>]

On Tue, Nov 03, 2009 at 09:33:28AM -0200, Roberto Ierusalimschy wrote:
> > > 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, ...)
> > 
> > Yes. :(
> 
> I am sorry, but I sent a wrong reply. I thought his proposal was to
> have an extra hidden (but unique) control variable before the visible
> variables in the loop. That is, the statement
> 
>   for a,b,c in exp do
> 
> would be really
> 
>   for _,a,b,c in exp do
> 
> with '_' hidden from the programmer.


What I had in mind was instead that we'd be able to do this:

for var_1, ..., var_n in my_next_function,initial_key,state1,...staten do
    stuff
end

which would be equivalent to this:

do
    local _f, _var, _s1 ... _sn = my_next_function, initial_key, state1, ..., staten
    while true do
        local var_1, ···, var_n = _f(_var, _s1, ... _sn)
        _var = var_1
        if _var == nil then break end
        stuff
    end
end

So there's still only one control variable. In the bit quoted below, Juris was talking about having multiple simultaneous control variables, which I can see might be useful when iterating nested structures. But I was only talking about increasing the number of static state variables.


On Tue, Nov 03, 2009 at 01:40:54PM +0200, Juris Kalnins wrote:
> If <dreaming> about iterators that could have been...
> 
> for var_1, ···, var_n in explist do block end
> 
> -- could be equivalent to the code:
> do
>   local f, s, ... = explist  -- all values returned by explist
>   while true do
>     local s, ..., var_1, ···, var_n = f(s, ...) -- call f with all
> values returned by previous iteration, assign leftmost n to control
> variables
>     if s == nil then break end
>     block
>   end
> end
> 
> I.e. for would not throw away extra values returned by iterator.
> When it returns nothing, loop would end.
> This would have made writing iterators for nested data structures
> (like filesystem) so easy...
> </dreaming>


-- 
Jim Pryor
jim@jimpryor.net