Re: [proposal] Libary changes

[Patrick Rapin <toupie300@...>]

>         #include "perl_extension.h"
> would trigger for C++ to become perl.

Whow, that would be cool ! And of course we also want to write in C++
  #include "lua_extension.h"
to import closures, coroutines, metatables, and dynamic variables into
that already powerful language...

I suspect Tarmo Pikaro to be a bit sarcastic.
The proposal of Sebastien Lai, to which I doesn't agree like
presented, is interesting however.
Until Lua 4.0, all library functions were global variables.
On Lua 5.0, most of them were moved into specific tables.
On Lua 5.1, the module system blessed the concept of a module as a table.
And in Lua 5.2, unpack moves into table.unpack. Several global
functions (loadstring, loadfile, setfenv, getfenv, module, newproxy)
are suppressed.

So there is a global trend toward removing global variables. There is
a trade-of to be done between modularity and ease of use.
We could for example move functions next, pairs, ipairs, rawget and
rawset into table.
That would make sense, but grow the average Lua code size because they
are frequently used (well, really?)

The three global variables Sebastien mentions (_G, _VERSION and arg)
are three special cases with no correlation between them.
That is why I found the proposal useless. _G is mostly replaced by the
upvalue _ENV in Lua 5.2. t
The arg table is on my point of view a legacy construct that should be
replaced with the "..." syntax.
So creating a sys table only for the remaining _VERSION isn't needed...