lua-users home
lua-l archive

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


Some comments:

On 30 Apr 2002, Victor Bogado da Silva Lins wrote:
> 	Here are some of my opinions about variables and scope.
> 
> 	Global variables are evil, they tend to block the reentrance of
> functions. They can be unadivertadly overwriten by calling a function
> that uses the same global as if they were locals (just to save the work
> of declaring them). 

This is true, they are one of the ugly things that can really mess up a
big software engineering project, or even a moderately large program an
individual puts together. But, well, Lua is as much an end-user language
as it is a language for professional programmers. The issues is much less
clear for the end-user programmer.

Most end-user programmers write fairly small peices of code: dozens of
lines rather than hundreds or thousands. Thus many of the ugly software
engineering issues are minimized or eliminated. It can, of course, be
argued that even end-user programmers can misspell variable names. I feel
this isn't the issue though. The question is if the overhead of having to
declare every variable is worth it to the end-user programmer who's
writting a twenty line script to make a non-player character in a game
smarter, or trying to automatically configure a router, or whatever.

(There's a very nice little book that talks about some of this by Bonnie
Nardi "A Small Matter of Programing". Worth a look).

> 	Undeclared use of variables are also a bad thing, shure they save time
> of the lazy (including me), but they can cost a day or two if you
> mispelled a single char in a long program. I do like them for quick
> prototypes and the like.

Again, this is a different matter for the novice/end-user programmer
who's just writing small embedded scripts.

> 	And here are some of my sujestions for the new version of lua.
> 
> 	A mode, or a sencond compiler, that will warn about common errors. Like
> reading a undefined variable.

I think this might be the answer to the problem. If we professional
programmers where to adopt some conventions and then write a LINT-like
program to go through and check out our code, we could get the benifits of
global declarations without making any changes to a language that really
works well for its intended task.

For example, we could state that all global variables must first be
assigned outside of a function scope. Like this:

     GlobalCounter = 0    -- "Declare" the global

     function dosomething(x)
         GlobalCounter = GlobalCounter + 1
         ....
     end

If we did not have the first assignment of the global outside of the
function declaration, then the "LINT checker" would give us an error
message.

The best part of this is we can write the "LINT checker" in 
Lua.  Personally would be glad to work on this.

 
> 	Each table should allow a parent table, one that will be used to look
> for undefined values in the child table. 

Fairly easy to do using metatables, though you have to define a special
slot in the table (I use "_parent") to store the parent object.
 
> 	Since there is two kinds of variables, a fast predeclared and a slow
> auto-generated. I would sugest that the user could declare both local
> and globals, every declared variable would be created in compile time.
> The undeclared variables are created at atribution time, if there is a
> table for the current block the variable will be stored there, otherwise
> a new table will be created for this block with the parent table set to
> the last "local table" created. 

Hmmm...I'm not sure I feel I can comment on this. Sounds okay, but I
expect there are hidden problems. If so I'm sure someone on the list will
spot them.

> 	Variable lookup would be recursive, search each "local table" for a
> defined value until you reach the "global table", if the variable is not
> defined then return nil.

Very slow. SILK (now JScheme) uses nested scope lookups like this and it
needs serious tweaking of the interpreter for it to do variable lookups in
less than geologic time. The form that works best is to use arrays for
local variables and a hash table for globals, which is not far off of
what's currently done in Lua. To be fair I'm not sure you expect the
"local tables" to be normal Lua tables.

> 	In my opinion this will be an incentive to declering variables, since
> it will make the program run faster. It will have local by default. And
> I think it would not have a huge impact in performance, since most
> program would have only two levels of "local tables".
> 
> -- 
> []'s Victor Bogado da Silva Lins
> victor@visgraf.impa.br
> 
> 
>