Re: locals again

[rw20@...]

> global.mySlot = "blah"
> 
> Another plus is that you would no longer have to declare local variables.
> Any variable that doesn't begin with self or global can be assumed local.

This method is like using a naming convention for global access and in my
opinion takes away for the language's style. 

I've been hacking on the Lua source to experiment with different options. 
I now have the following implemented: 

1. $globals, $noglobals to turn on and off global variable access inside 
functions.

2. a 'global' keyword like 'local' that turns on access within one 
function for the names in the list.

The good thing about this system is that code written with the 'global' 
and 'local' keywords works in $globals and in $noglobals mode.  Of course 
you get enhance error checking in $noglobals mode.

Example:
z=3
g=-56
function test() 
local x
global z,g
	x=z+g
	print(abs(x))
end

I've thought about experimentally making 'local' optional since it seems a
little redundant.  The problem with omitting it is that you can then 
write code which does different things depending on the access mode.  
That seems really confusing to me:

$globals
function g() x=3; end -- creates a global
$noglobals 
function g() x=3; end -- creates a local

That's bad.

The only way, I can think of, not to require the 'local' keyword (a nice
language simplification I think) is to have a 'method...end' syntax.  So
'method...end' automatically manages the Lua global access mode, sort of
like writing '$noglobals function...end $globals' all the time. 

There seems to be two good final forms to me:

1. $noglobals, $globals, require 'local' and 'global' lists to write code 
that works in either mode.
(Would $global [on|off] or something else be a better syntax?)

2. function...end, method...end, globals list required in methods and 
local list required in function
(Is there a better word than 'method' for this?)

I'm reasonable happy with either; they both have there advantages.  Option
1 has the advantage of creating a new coding standard that always works,
but may create some confusion as to what mode Lua is or even should be in
for a particular piece of code (especially confusing for those of use who
like to cut and paste code together).  Option 2 has the advantage of
clearly separating the access modes and only requiring one list of
variables (since one access mode is assumed).  Option 2 may confuse
beginner programmers as has been pointed out, but only one of the
constructs is required for any system, so just pick the one you like. 

Would anyone like to experiment with the modifications I made (all the
mods are in lex.c, parser.c, parser.h, and lua.stx)?  I'm just trying to
help people think about a standard Lua answer to this issue. 

I hope people aren't getting sick of this issue.

Russ Webb