Re: Making Lua lexically scoped (was: Re: Proper tail recursion)

["Everett L.(Rett) Williams" <rett@...>]

Reuben,

> > It also points out the dangers of using antediluvian sources:-) Very few
> > meet the test of time. The question that I have is why do we need global
> > variables. If the language becomes fully lexically scoped, then variables
> > declared at the proper level will become visible at all levels below.
> > Why build a separate table for global variables. Just seems unnecessary,
> > time consuming, and a creater of more baggage to haul around.
>
> Every file is a separate scope (you can declare locals at the top level, as
> the file as a whole is a chunk), so if you had no globals, you wouldn't be
> able to share values between files; dofile("foo") couldn't leave any values
> in the namespace &c.

Well, the problem here is the nature of lua as designed. It was designed to
be an embedded language, and the usage that I see in that regard is highly
complex. Sometimes lua calls C(insert your favorite language here), and
sometimes C calls lua, and many times, they call each other in many different
guises. This kind of usage begs for either a very narrow pipe or no pipe at
all for variables. That is to say, either you should carefully pick only the
things that are absolutely needed for the particular call, or you should have
a fairly flat(read global) namespace for all routines. The problem with  a flat
namespace is conflicts, and the remedies for those conflicts. The problem
with flat or global namespaces is that they create real problems when the
interpreter can be called again at any time to deal with a new "chunk" with
it's new-to-the-interpreter variable set.

On the other hand, when lua is used as a stand-alone development language,
it is much more inviting to have modularization, and narrow pipes with control
over which variables go where.

> Of course, you could get around this by changing things so that the top
> level of every file is the *same* scope, and I agree that it's arguable that
> using locals at the top level (outside a function or block) doesn't look
> like good style.
>
> However, I suspect this would be difficult to compile, since local variables
> are normally accessed by index; this relies on the compiler's knowing all
> the locals in advance, which it can't if you allow multiple files to create
> locals in the same scope.

However difficult that it might be, if we are talking about lexical scoping, we
are going to be dealing with locals in a very different way. Let us assume that the
namespace/environment at the point that a chunk is invoked along with all the
namespace/environment that it has inherited is the set of "upvalues" for that
chunk which now have no need of definition. Again, I don't see the need for globals.
Globals are the items defined at the topmost level of the tree or that are promoted
to that level. Now, you can talk about things that are relatively global to a whole
branch of the tree, but you always have room for another level. The problem with
the concept of global is that it marks a particular level of code as being the "master"
or topmost level. Then, when we want to share or re-use items, we must account
for a "re-mastering" of the code and we all know what kind of effort that involves.

Everett L.(Rett) Williams
rett@gvtc.com