[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: "global": other scripting languages & suggestion
- From: "Tom " <tmb@...>
- Date: Wed, 13 Sep 2000 01:35:36 -0000
> this `i' is not "automatically local". If you want a local `i', you
> say so. The same is true in C++, Pascal, Java, Perl, Ada, FORTRAN,
> Simula, Smalltalk, SNOBOL, ML, Haskell, etc. etc. (Tcl is one of the
The issue is really how easy it is to make a mistake.
In C, C++, Pascal, Java, Perl, Ada, Scheme, ML, Haskell (and
others), you have to declare a variable globally before you can
refer to it in a local scope. Furthermore, in most of
those languages, you will get a compile-time error unless
the global definition is, in fact, available at compile-time,
which further reduces the probability of clobbering something
Perl (strict), Python, and Tcl all require global
variables used inside procedures to be explicitly declared
as such. Perl will complain if you don't explicitly declare
the variable as either global or local, and Python and Tcl will
make it implicitly local. Past experience in scripting
languages seemed to show that making variables implicitly global,
is simply too error prone.
Implicitly global doesn't only cause problems with accidental
clobbering of global variables (which occasionally occurs
even in languages like C/C++), but also with unexpected
retention. If, in Lua, you forget "local", your program
may run fine and correctly, but large data structures may
never get garbage collected.
I think this is probably the biggest language design issue
with Lua. I have puzzled over bugs resulting from this
even though I knew about it, and I think it's simply error
prone. Otherwise, I think the Lua language design is great.
How could this be addressed if people wanted to?
Adding a "global" keyword wouldn't be hard. How
to handle older Lua code then becomes a tricky question, though.
For simplicity, I would probably aim for an incompatible
change in the long term, rather than supporting both
semantics in perpetuity. In the short term, implicitly
global variables and the "local" keyword could produce
a warning that could be disabled via a command line flag.
By default, only the first occurrence in a program would
produce a warning, but to help with porting, a verbose warning
could print a message every time it occurs. For an even
more gentle transition, the new semantics might initially
require enabling via a command line flag.