Re: proposal for change in for protocol

[Duncan Cross <duncan.cross@...>]

On Tue, Apr 3, 2012 at 12:29 PM, Cosmin Apreutesei
<cosmin.apreutesei@gmail.com> wrote:
> Hi,
>
> What would you think of a change in the for protocol like this:
>
>     do
>       local f, s, var_1, ···, var_n = explist --keep all init values
>       while true do
>         local var_1, ···, var_n = f(s, var_1, ···, var_n)

I think the main problem is here - f() can return any number of
values, not just the same number "n" as the number of initial values.
The "local var_1, ... var_n" list inside the while loop would not be
like a normal set of local variables, as the pseudocode implies, but
instead would have to be a dynamic allocation (similar to the '...'
varargs structure) to accommodate what f() chooses to return. This can
probably be done in a clever way, but I suspect it would still cancel
out the gains you hope to make by allowing more state values.

(Also, I think you made a mistake in your pseudocode that means f()
would only ever be called with the initial state values, not the most
recent ones.)

>         if var_1 == nil then break end
>         block
>       end
>     end
>
> Pros:
> - allow one to write heapless stateless iterators like values(t) that
> can be used in tight loops - I suspect the idiom for _,v in ipairs(t)
> is because _ is the state that currently cannot be hidden.

That seems like a bad example - in my experience, the index value in
an ipairs loop is useful more often than not.

-Duncan