global scope revisited

["John Belmonte" <jvb@...>]

I've written before about issues regarding Lua treating the global scope as
a special case.  I'd like to try again, hopefully with a clearer description
of the problem and proposed Lua change.

With Lua 4.0, the global scope has become just another table.  We can access
and even change that table with the globals() function.

The problem is that even though a table can become the "global" table, it is
not accessed as a table with respect to events.  The "index", "gettable" and
"settable" tag methods are not called.  In their place are the "getglobal"
and "setglobal" tag methods which have different semantics and provide only
a subset of the functionality.

When defining extensions using tag methods, the special case of the global
scope can cause the following lines to produce different results:

    a = 5  -- calls setglobal tag method for previous value of "a"
    globals().a = 5  -- calls settable tag method for global table

To a certain degree it's possible to design extensions to behave the same in
both cases.  However since the global events are a subset of the table
events this isn't always possible.  For example in the first line above, if
the global "a" previously had a value with a default tag then no event is
available.

The current system, in addition to being confusing and requiring extra event
types to handle the global case, prevents a number of useful programming
paradigms such as Python-style namespaces and modules.

The change to Lua that I would like to see is that reads and writes of the
global environment (from both Lua and the API) be made to have the same
meaning as access to the global table object, and that the following tag
methods be deprecated:

    getglobal
    setglobal

This can be done with full backwards compatibility.  The default global
table can have its tag methods set to implement the "getglobal" and
"setglobal" events with exactly the same semantics they have now.  Users not
needing the old functionality can replace the default tag methods with their
own.

My question to the Lua designers is would you consider this change.  If the
value is not easily apparent or the backward compatibility suspect, I can
address those issues more.

Regards,
-John