Re: global/local a misnomer?

[David Manura <dm.lua@...>]

Kein-Hong Man <mkh <at> pl.jaring.my> writes:

> 
> David Manura wrote:
> > [snip]
> > However, in Lua, this need not be the case at all.  A global
> > variable may be placed in an environment that is local to a
> > single function (what you call "non-global environments"),
> > and a local variable can be placed at the top-level scope:
> > [snip]
> 
> As a user, I have never been confused. Perhaps you should read 
> Roberto's "Programming in Lua" book instead of looking at the 
> wiki. Learn it as a language without trying to force things from 
> other languages onto it. Browse the wiki after you do "Programming 
> in Lua" and the reference manual. I won't even try to address the 
> issues you've raised -- they have been amply discussed on the 
> list; you can search the archives.
> 

Hello Kein-Hong Man,

I understand how it works but was more curious why it was that way and
wanted to point out the impressions of a new user.  I have read both
PIL and the reference manual in full, as well as ~half of your very
useful guide on the VM internals.  In any case, I'll be scanning
through the archives in more depth.  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."

A few more "impressions" of a new user:

(1) A major impression I had was of the inability to store nil values
in a table.  This has some implications such as not really being able
to store an argument list "..." in a table (and then use unpack) since
the argument list might contain nil values.

(2) The "level" argument in error(message, [,level]) sometimes seem
hard to specify if a function can be called from multiple different
levels.  Perl Carp addresses the same problem with a solution that
works in conjunction with the package mechanism
(http://perldoc.perl.org/Carp.html), so you don't have to specify a
precise level.

(3) A true "ternary operator" can be less worrisome:
http://lua-users.org/wiki/ExpressionsTutorial .

(4) Lua seems to use a combination of both begin/end type blocks
(sometimes without the "begin" as in function) and braces/parenthesis.
This is unlike C (which just uses braces/parenthesis) and Pascal
(which mainly uses begin/end type blocks).  This combination sometimes
seems to visually clash, though maybe I'm just not used to it:

  setmetatable(env, {
    __newindex = function(t, k, v)
      ...
    end,
    __index = function(t, k)
    end
  })

(5) Happily, the "n" key was removed in Lua 5.1 tables (thank you!)

(6) I've found some useful tricks with Lua's data description
capabilities, e.g.  Lua supports the syntax

  circle(0) {...}

if you define circle as a function that returns another function that
evaluates the table.  Sometimes, one might want to do things like
this:

  circle 0
  circle x

as syntactic sugar for circle(0) and circle(x).  Currently, Lua only
does that for strings and and tables.

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.

--davidm