Re: global/local a misnomer?

[Kein-Hong Man <mkh@...>]

Hi David,

David Manura wrote:
> Kein-Hong Man <mkh <at> pl.jaring.my> writes:
> > David Manura wrote:
> > > [snip] [snip] [snip]
> [snip] My main point was that the main
> distinguishing property of Lua "globals" is not that they are
> necessarily "global" but rather that they are resolved at run-time.
> As PIL says, "That may sound strange at first; after all, the goal of
> a table of global variables is to be global."

Okay, there does not seem to be anyone else on this thread so I 
will take a stab at discussing some of this.

Cut out the metatables, environments and _G first, then globals 
will be globals and locals will be locals, and Lua will look like 
a pretty conventional procedural language. Metatables, 
environments, _G are all more advanced stuff based on the table 
paradigm of Lua. A user frequently need not deal with the more 
advanced stuff, but it is there for power users or users who need 
such lower-level mechanisms to implement stuff.

A source file by itself is a chunk, or an anonymous function. 
Therefore you can define locals "outside a function" in a source 
file -- they are really local to the chunk which is the source 
file. So locals are still locals and globals are still globals, 
but it will look like a magic act to people who are used to C, for 
example. _G is merely a lower-level mechanism; you should not let 
it confuse your local/global variable thinking.

> (1) [snip] inability to store nil values [snip]
> (2) [snip] The "level" argument in error [snip]
> (3) [snip] A true "ternary operator" [snip]

I can't address these; I am not too particular about such things, 
as long as Lua's behaviour is well-defined. I can always adjust my 
methods, or customize Lua. But you will find discussions in the 
list archives about such things, especially item (1).

> (4) [snip] a combination of both begin/end type blocks [snip]

(a) Begin...end type of blocks are a bunch of statements.
(b) Braces are table constructors.
(c) Parentheses are argument lists or expressions.

There is a one-to-one mapping, so no confusion. The great thing 
about Lua is that it is easy for the average coder to fit the 
whole language and most of the libraries into one's head. You just 
need to mess around with Lua more in order to grok it. The problem 
is the way such syntax can be mixed; it does take a little time to 
get used to it.

> (5) [snip]
> (6) [snip]
> A lot of positive things could be said too, e.g. Lua's support for
> multiple return values, coroutines, and closures and it's efficiency
> and ability for data description--all in a very small package that is
> fairly easy to customize/embed.  These have all been pointed out
> before, but, indeed, they are the reasons I am currently using Lua.

Lua fills an important niche in the market, for the reasons you 
describe above and most users will agree with you. It is 
fundamentally different from a swiss army knife kind of scripting 
language (there is LuaCheia to fill that niche.) I do think Lua 
has inspired a whole bunch of small embeddable languages.

--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia