AW: AW: non-locals are only sometimes global?

["Warlich, Christof" <christof.warlich@...>]

Ok, so as an example, nested loops would clash if they use the same loop variables, right? That's a good point. As a C++ programmer, I still need to get used to that philosophy :-).

But on the other hand, globals may always cause unexpected influences between different parts of code, so why making an exception just for loops? Instead, one could have forced the programmer to use the "local" keyword for loops as well to avoid any trouble with globals that should have been local, e.g.:

for local word in data:gmatch("(%S+)%s*") do
    print(word)
end

Unfortunately, the Lua interpreter doesn't even accept the "local" keyword at this position.

Anyway, that's just my personal taste, and now that I know, I can easily live with it as it is right now. Though I would welcome to change that for Lua 5.2, at least allowing the local keyword, as it would not break backward compatibility.

Cheers,

Christof

> -----Ursprüngliche Nachricht-----
> Von: lua-bounces@bazar2.conectiva.com.br [mailto:lua-
> bounces@bazar2.conectiva.com.br] Im Auftrag von Peter Odding
> Gesendet: Mittwoch, 21. Juli 2010 12:49
> An: Lua list
> Betreff: Re: AW: non-locals are only sometimes global?
> 
> > Yes, thats obvoius now. But it seems to be a rather unexpected exception
> > to me. It there any rationale behind this exception?
> 
> If loop variables were global by default then only a single loop can be
> active at any given time, because the loop variables would clash?* Maybe
> that doesn't sound too bad but consider using two modules (by different
> authors) in your code which both use a for i = 1, N loop and the two
> loops overlap without your specific knowledge. That could break either
> module at any given time though the code of either module would look
> perfectly fine when you try to find the bug...
> 
>   - Peter Odding
> 
> * Of course a for i = 1, N loop will always run from 1 to N,
> irrespective of any other loops in the code, but my point was that any
> use of the variable "i" could pick up the "i" from either module...