Re: locals again

[rw20@...]

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

No.

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

Interesting idea.  I can live with functions and pragmas to control lua
though.  I find pragmas a little ugly, but at least they stand out (this
lua.xxx syntax would too).  This syntax would perhaps be more uniform, 
but Lua would have to support both syntaxes so why bother.  You could 
probably write something like this in Lua if there is a settableentry 
tag (I can't remember) just by mapping assignments to the needed function.

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

Good point.  Maybe the something like what I've already implemented is 
all that's needed.  Mistakenly accessing a local would be a problem and 
would cause some strange runtime behavior, so I guess the local 
declarations aren't redundant.  

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

You can use tags and special tables, but it still doesn't really fix the 
problem of having strange runtime behavior that's hard to debug.  Let's 
say we need control over variable access not static typing (shudder).

Russ