lua-users home
lua-l archive

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

Hi David,

David Manura wrote:
Kein-Hong Man <mkh <at>> 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.

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