Variables

  • 访问一个不存在的全局变量得到nil
  • 释放一个全局变量只需将其赋值为nil，效果与未定义该变量一样
  • Lua 中的变量全是全局变量，那怕是语句块或是函数里，除非用 local 显式声明为局部变量
  • 局部变量比全局变量访问更快

Functions

1. 基本特性

  1. 多参数/返回值匹配：多余忽略，缺少用nil补足
  2. 可变参数：arg，table.pack，table.unpack
  3. 命名参数：参数的非顺序填充方式
  4. 正确处理尾调用：Lua能够高效正确处理尾调用，而不会导致栈溢出

2. 第一类函数

函数是第一类值，函数可以像其它值（string, number）样用于赋给变量，作为函数参数或返回值。函数定义实际上是一个赋值语句，将类型为function的变量赋给一个变量。

1
2
3
function  (x) return 2*x end

foo.bar = function (x) return 2*x end

从这个角度来看，自然，与变量一样，Lua有全局函数和局部函数之分。

3. 词法闭包

词法闭包是指当在一个函数内部嵌套定义另一个函数时，内部函数体可以访问到外部函数的局部变量。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
function newCounter()
    local i = 0
    return function()     -- anonymous function
        i = i + 1
        return i
    end
end
c1 = newCounter()
print(c1())  --> 1
print(c1())  --> 2
c2 = newCounter()
print(c2())  --> 1

-- 打印c1所有的upvalue 输出: i
local i=1
local up = debug.getupvalue(c1, i)
while(up ~= nil) do
    print(up, "  ")
    i = i+1
    up = debug.getupvalue(c1, i)
end
print(c1, c2) -- function: 0x7f8df1d02100        function: 0x7f8df1d02160

这种情况下，我们称i为匿名函数的外部局部变量(external local variable)或upvalue。在这里，newCounter函数返回了一个闭包(closure)。闭包是指一个函数和它的upvalues，闭包机制保证了即使upvalue已经超出了其作用域(newCounter返回)，仍然能正确被闭包函数引用而不会释放(由Lua GC管理)。在上例中，我们说c1和c2是建立在同一个函数上，但作用于同一个局部变量(i)不同实例的两个不同的闭包。

通过打印的upvalues可以看到，只有被闭包函数引用的外部局部变量，才算作该闭包函数的upvalue，Lua会按照闭包函数引用的顺序为upvalue编号，该编号与upvalue定义顺序无关。

最后一点是，闭包函数都是动态生成的，这和Go中的闭包有所不同，Go的闭包函数是在编译时生成的，不同的闭包可以共享闭包函数(同一个函数地址)。Lua的闭包函数动态生成会一定程度地影响运行效率和内存占用。

Lua闭包除了用于高级函数，回调函数，迭代器等上下文环境中以外，在完全不同的上下文环境，可用于重定义或预定义函数，通过这种方法，可以为代码创建一个安全的执行环境(也叫沙箱，sandbox)。

Lua还提供了对C闭包的支持，每当你在Lua中创建一个新的C函数，你可以将这个函数与任意多个upvalues联系起来，每一个upvalue 可以持有一个单独的Lua值。当函数被调用的时候，可以通过假索引(lua_upvalueindex)自由的访问任何一个upvalues。

1
2
3
4
5
6
7
8
9
10
11
12
13
static int counter (lua_State *L) {
    double val = lua_tonumber(L, lua_upvalueindex(1));
    lua_pushnumber(L, ++val);   /* new value */
    lua_pushvalue(L, -1);       /* duplicate it */
    lua_replace(L, lua_upvalueindex(1));  /* update upvalue */
    return 1;  /* return new value */
}

int newCounter (lua_State *L) {
    lua_pushnumber(L, 0);
    lua_pushcclosure(L, &counter, 1);
    return 1;
}

C闭包与Lua闭包在概念上很相似，但有两点不同：

  1. C函数的upvalues是显示push到栈中的，而Lua则可通过闭包函数引用确定哪些是upvalues
  2. C闭包不能共享upvalues，每个闭包在栈中都有独立的变量集，但你可以通过将upvalues指向同一个table来实现共享

Chunk

Chunk是一系列语句，Lua执行的每一块语句，比如一个文件或者交互模式下的每一行都是一个Chunk。

当我们执行loadfile(“test.lua”)时，便将test.lua的内容编译后的Chunk作为一个函数返回，如果出现编译错误，则返回nil和错误信息。而dofile相当于:

1
2
3
4
function dofile (filename)
    local f = assert(loadfile(filename))
    return f()
end

loadstring和dostring的关系类似，只是接收字符串而不是文件名为参数。

再看require，require和dofile完成同样的功能，但主要有几点不同：

  1. require会搜索Lua环境目录来加载文件
  2. require会判断文件是否已经加载而避免重复加载统一文件
  3. require可以用于加载C .so库，功能类似loadlib，参考这里

一个lua模块编译后的Chunk被作为匿名函数被执行，那么定义于模块中函数对模块局部变量的引用就形成了闭包，所以说Lua中的闭包真是无处不在。

Enviroment

Lua中的环境用table来表示，这简化了环境处理也带来了不少灵活性。

在Lua5.1及之前，Lua将环境本身存储在一个全局变量_G中，其中包含了全局变量，内置函数，内置模块等。我们在使用任何符号x时，如果在当前函数的局部变量和upvalues无法找到符号定义(PS: Lua查找变量定义的规则为：局部变量 -> 外部局部变量(upvalue) -> 全局变量)，则会返回_G.x的值。由于_G是一个table，因此我们可以用它实现一些有意思的功能：

  1. 通过动态名字访问全局变量： _G[varname]
  2. 通过_G的metatable改变对未定义全局变量的读(__index)和写(__newindex)行为
  3. 通过setfenv改变指定函数的_G环境，制造函数执行的沙盒环境

现在再回头来看闭包，实际上，Lua闭包除了函数和upvalues，还包括函数环境，这三者组成了一个完整的执行沙盒。

在Lua5.2及之后，Lua取消了setfenv函数，用_ENV方案替代了_G方案：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
-- before Lua 5.1
function f()
  setfenv(1, {})
  -- code here
end

-- after Lua 5.2
function f()
  local _ENV = {}
  -- code here
end
or
function f()
    local _ENV = {}
    return function() ... end
end

_ENV有三个特性：

  1. 对全局变量x的引用，将转换为_ENV.x
  2. 每个编译后的Chunk，都有一个_ENV upvalue(哪怕并未使用)，作为Chunk环境，并作用于其内定义的函数
  3. 在初始化时，_ENV=_G

除了以上三点外，_ENV和普通变量并无区别。因此我们可以直接通过local _ENV = {}来覆盖接下来的代码的环境。将环境(_ENV)作为一个普通的upvalue来处理，这样做的好处是简化了闭包的概念，闭包等于函数加upvalues(没有了全局变量_G)，为闭包优化(如合并相同upvalues的闭包)提供更好的支持，同时也减少了setfenv(f, env)带来的不确定性和不安全性(函数的_ENV upvalue在闭包返回时就已经确定了)。

有_ENV还是一个table，因此对全局变量的访问控制等trick，仍然很容易实现。Lua目前仍然保留_G，但理解它们的别是比较重要的：

我们都知道Lua有一个全局注册表(Registry)，其中包含整个Lua虚拟机的信息，在Registry的LUA_RIDX_GLOBALS索引中，保存了Globals(也就是_G)，在创建Globals时，会生成_G._G=_G的自引用。在引入_ENV后，初始时，_ENV=_G，一旦编译器将_ENV放入Chunk的upvalue后，_ENV将作为普通upvalue被看待，因此我们可以对其重新赋值：

1
2
3
4
5
6
7
8
9
10
11
12
i = 1 -- 此时 _ENV.i == _G.i == 1
function f()
    local _ENV={i=2, print=print, _G=_G}
    print(i, _ENV.i, _G.i)
end

function g()
    print(i, _ENV.i, _G.i)
end

f() -- 2 2 1
g() -- 1 1 1

因此，_ENV除了在创建时和_G都指向Registry[LUA_RIDX_GLOBALS]之外，和_G并没有直接联系(_G={}不会影响函数环境，_G.x=1仍然会影响注册表中的Globals)，Lua5.2及之后的环境都由_ENV指定，_G出于历史原因保留，但实际上Lua并不在内部再使用：

Lua keeps a distinguished environment called the global environment. This value is kept at a special index in the C registry (see §4.5). In Lua, the global variable _G is initialized with this same value. (_G is never used internally.)

Packages

在Lua中，有闭包，灵活的table和环境管理，想要实现包管理有非常多的方法：

1. 基本方法

最简单的方法就是直接使用table和第一类函数特性：

1
2
3
4
5
complex = {}
function complex.new(r,i) ... end
function complex.add(c1,c2) ... end
...
return complex

执行这个Chunk后，便可以通过complex.xxx()使用complex中定义的API了。这种方案主要的缺点是包内包外的调用都必须加上前缀，并且不能很好地隐藏私有成员。

2. 局部函数

通过局部函数再导出的方式，我们可以解决包内调用前缀和隐藏私有成员(不导出即可)的问题。

1
2
3
4
5
local function new(r,i) ... end
local function add(c1,c2) ... end
...
complex = {new = new, add = add}
return complex

但这样容易忘了local，造成全局命名空间污染。

3. 独立环境

1
2
3
4
5
6
7
complex = {}
-- before Lua5.1: setfenv(1, complex)
local _ENV = complex

function new(r,  i) ... end
function new(c1, c2) ... end
return complex

现在，包内所有全局符号new, add都会被转换为complex.new, complex.add，并且我们为包创建了一个独立沙盒环境，如果要在包内访问全局符号，也有多种方法:

1
2
3
4
5
6
7
-- 方案1: 保存老的全局环境 之后访问全局符号需要加上 _G.前缀
local _G = _G
-- 方案2: 通过metatable 效率低一些，并且外部可通过complex.print访问_G.print
setmetatable(complex, {__index = _G})
-- 方案3: 只导出要使用的函数 这种方法隔离型更好，并且更快
local sqrt = math.sqrt
local print = print