lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


> 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.

This looks very useful and I think it, or something like it, should be
considered for inclusion in the standard version.

Do these directives have any effect outside functions (i.e., at the
main level)?

Another option, and one that might be retroactively applied to the
$debug directive, would be to have a global table-like variable called
lua with members lua.debug and lua.defaultglobals that can be nil or
non-nil (and I hope you know how much it hurt not to say `true or
false' there). A suitable gettable/settable method would set the
internal C variable. I think this is cleaner, more flexible, and
better potential for growth than directives.

Other members could be lua.version, lua.stack, to get access to the
call stack, and lua.error, which would replace the seterrormethod
function.

> I've thought about experimentally making 'local' optional since it seems a
> little redundant.  

Unless I misunderstand what you've done, I don't think local
declarations are redundant. If you have non-declared names reference
local variables by default, any misspelled global name erroneously and
silently references a local variable. Clearly, this is an error just
as having misspelled global variables erroneously and silently
reference global variables. This is the kind of error you are trying
to prevent, yes?

Earlier I had voiced my concern that this did nothing for spelling
mistakes in table indices. However, I've realized that you can get
around this most of the time by defining appropriate table types with
settable/gettable methods that check the validity of the indices. Of
course, this will only give you a run-time error, but without a static
type system I don't think there's much else we can do.

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

I can't speak for anyone else, but I'm not getting sick of this at all.

Regards,

Alan Watson