Re: Implicit Globals - A compile time solution.

["Francisco Sant'anna" <francisco.santanna@...>]

Don't know if I got your point, but, even if you are lazy to declare locals you still can't write code like this:

<... some lines of code before ...>

function ()
    i = 0  -- you still need the local before
    while i < 5 do

        ...
        i = i + 1

    end
end

Because you never know if the variable i was already assigned before in your code, so you have two options:
1- see if you have already assigned to i
2- put the word local before it (now we have only this option)
I think (1) is not reasonable.
So you'd do exactly the same we do now with "global by default".
This is exactly the "esoteric case of overriding an upvalue" that you first mentioned, which would be living in the outermost scope.

About polluting the global namespace we already have a solution, which is not bad, that is to call module() without the package.seeall flag.

Maybe what you want is a new operator for assignment that would have the "local by default" rule, something like:
i := 0

And maybe a different behaviour for require that still pollutes the global namespace.

--
Francisco

On Thu, Feb 21, 2008 at 2:35 PM, John Hind <john.hind@zen.co.uk> wrote:

David Given said:

<<
Give that your original suggestion was that global-by-default causes
pollution of the global namespace if you forget to declare a variable, I'd
suggest that this approach to local-by-default causes pollution of the local
namespace instead --- which I think is exactly the same problem!
>>

Whenever you define a variable you are polluting *some* namespace and it is
good programming practice to make that the most local space possible.
Global-by-default is much worse on this count because it can stomp on stuff
*already compiled* even parts of the *standard libraries*! Remember that
globals are run-time bound while locals are compile-time, so at least the
code you are breaking with locals is in the same file or chunk.