Re: Scopes, and Named Parameters?

["Peter Hill" <corwin@...>]

>> In your function f I left above, currently the local keyword is require
>> to keep a,b,c from going into the global scope. Is that ever going to
>> change?

Luiz Henrique de Figueiredo:
> Not likely.

I not sure which way I lean on this but I was wondering what the current
official rationale of the no "global a,b,c" policy is.

It seems to me that it could be added in an upward compatible (ie, optional)
fashion, and that aside from the obvious use (of requiring explicit variable
declarations _for those who wish it_) it could also be used to re-enable
access to a shadowed global. In a rather contrived example we have:
  do
    -- Create a new lexically scoped local variable.
    local x = 1
    p = function () x=x+1 return x end

    -- Create a second new lexically scoped local variable, overshadowing
    -- the first 'x'.
    local x = "#"
    q = function () x=x.."#" return x end

    -- Provide access to the global variable, overshadowing the second 'x'.
    global x
    r = function () x=x+2 end
  end

As the distinction is detected at compile time there should be no extra
runtime overhead.


As far as the optional nature goes, Lua would provide an internal function
(or get/set function pair) that responds to accesses to undefined globals.

The default value of these functions simply allows normal access.

If someone wishes to restrict undefined access they can alter these
functions as desired. Eg:
    _UNDEF_SET = function (g,v) error("Attempt to set an undefined global'"
      ..g.."'") end
    _UNDEF_GET = function (g) error("Attempt to get an undefined global'"
      ..g.."'") end

Note: These functions are activated by access to an _undefined_ global (in
the sense of having no "global a,b,c" statement, which makes a note in the
compiler's symbol table) as  opposed to an _uninitialised_ global (in the
sense of being defined but having a 'nil' value).

*cheers*
Peter Hill.