for namelist in iterator do
   block
end

其中iterator是一个迭代器函数，它可以有一个或多个返回值，namelist是逗号分隔的循环变量名列表，用来接收每次调用迭代器函数得到的返回值。这段程序的语义与下面形式的代码相同:

while true do
   local namelist = iterator()
   if nil == first(namelist) then break end
   block
end

first(namelist)表示namelist的第一个变量名。

    Lua已经提供了若干个常用的迭代器生成函数，最常见的就是ipairs和pairs。ipairs(t)以一个table作为参数，生成一个依次返回(1,t[1])、(2,t[2])、(3,t[3])......的迭代器。下面这段代码

t = {"Monday","Tuesday", "Wednesday","Thursday", "Friday","Saturday","Sunday"}

for i,v in ipairs(t) do
   print(i,v)
end

将会打印出

1        Monday
2        Tuesday
3        Wednesday
4        Thursday
5        Friday
6        Saturday
7        Sunday

。pairs同样用一个table作为参数，它生成的迭代器依次返回该表中所有的key和value。

    Generic for搭配ipairs和pairs用起来相当方便，但是它们却有一个很难察觉的缺陷。看看这段代码:

for i,v in ipairs(t) do
  print(i,v)
  -- some code changes i
  i = 0
end

许多人(包括我)都猜不出它竟然会不停地疯狂打印

1        Monday

，如果用pairs替代ipairs也不会好到哪里去: 在打印出一行数据后便抛出个 invalid key for `next' 错误。

    由此可知，使用了ipairs和pairs的Generic for在语义与上文while true ... end形式的代码并不完全相同，它们生成的迭代器需要使用循环变量，而如果循环体改变了循环变量值的话，那么迭代器就很可能会象在本例中那样找不着北了。因此，《Programming in Lua》的4.3.5中便有这么一段谆谆告诫: “The generic loop shares two properties with the numeric loop: The loop variables are local to the loop body and you should never assign any value to the loop variables. "。

    ipairs和pairs的这个缺陷是由于它们要用当前循环变量的值来作为下一次迭代的起点，那么这是不是必需的呢？当然不是，我们完全可以通过closure来实现一个更安全的ipairs :

function myipairs (t)
   local i = 0
   local n = table.getn(t)
   return function ()
             i = i + 1
             if i <= n then return i,t[i] end
          end
end

t = {"Monday","Tuesday", "Wednesday","Thursday", "Friday","Saturday","Sunday"}

for i,v in myipairs(t) do
  print(i,v)
  -- some code changes i
  i = 0
end

    试试上面这段代码，怎么样？是不是工作得很好？为什么它不会发疯？其实很简单，myipairs生成的迭代器(一个closure)把需要用到的迭代信息保存到它的upvalue(i和n)中，这样即使循环体更改了循环变量也不会影响到迭代状态。感谢closure，我们终于可以放心大胆地粗心一点了！^_^

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=564518

function f1(n)
   -- 函数参数也是局部变量

   local function f2()
      print(n) -- 引用外包函数的局部变量
   end
   return f2
end

g1 = f1(1979)
g1() -- 打印出1979
g2 = f1(500)
g2() -- 打印出500

当执行完g1 = f1(1979)后，局部变量n的生命本该结束，但因为它已经成了内嵌函数f2(它又被赋给了变量g1)的upvalue，所以它仍然能以某种形式继续“存活”下来，从而令g1()打印出正确的值。

    可为什么g2与g1的函数体一样(都是f1的内嵌函数f2的函数体)，但打印值不同？这就涉及到一个相当重要的概念——闭包(closure)。事实上，Lua编译一个函数时，会为它生成一个原型(prototype)，其中包含了函数体对应的虚拟机指令、函数用到的常量值(数，文本字符串等等)和一些调试信息。在运行时，每当Lua执行一个形如function...end 这样的表达式时，它就会创建一个新的数据对象，其中包含了相应函数原型的引用、环境(environment，用来查找全局变量的表)的引用以及一个由所有upvalue引用组成的数组，而这个数据对象就称为闭包。由此可见，函数是编译期概念，是静态的，而闭包是运行期概念，是动态的。g1和g2的值严格来说不是函数而是闭包，并且是两个不相同的闭包，而每个闭包可以保有自己的upvalue值，所以g1和g2打印出的结果当然就不一样了。虽然闭包和函数是本质不同的概念，但为了方便，且在不引起混淆的情况下，我们对它们不做区分。

    使用upvalue很方便，但它们的语义也很微妙，需要引起注意。比如将f1函数改成：

function f1(n)
   local function f2()
      print(n)
   end
   n = n + 10
   return f2
end

g1 = f1(1979)
g1() -- 打印出1989

内嵌函数定义在n = n + 10这条语句之前，可为什么g1()打印出的却是1989？upvalue实际是局部变量，而局部变量是保存在函数堆栈框架上(stack frame)的，所以只要upvalue还没有离开自己的作用域，它就一直生存在函数堆栈上。这种情况下，闭包将通过指向堆栈上的upvalue的引用来访问它们，一旦upvalue即将离开自己的作用域(这也意味着它马上要从堆栈中消失)，闭包就会为它分配空间并保存当前的值，以后便可通过指向新分配空间的引用来访问该upvalue。当执行到f1(1979)的n = n + 10时，闭包已经创建了，但是n并没有离开作用域，所以闭包仍然引用堆栈上的n，当return f2完成时，n即将结束生命，此时闭包便将n(已经是1989了)复制到自己管理的空间中以便将来访问。弄清楚了内部的秘密后，运行结果就不难解释了。

upvalue还可以为闭包之间提供一种数据共享的机制。试看下例：

function Create(n)
   local function foo1()
      print(n)
   end

   local function foo2()
      n = n + 10
   end

   return foo1,foo2
end

f1,f2 = Create(1979)
f1() -- 打印1979
f2()
f1() -- 打印1989
f2()
f1() -- 打印1999

f1,f2这两个闭包的原型分别是Create中的内嵌函数foo1和foo2，而foo1和foo2引用的upvalue是同一个，即Create的局部变量n。前面已说过，执行完Create调用后，闭包会把堆栈上n的值复制出来，那么是否f1和f2就分别拥有一个n的拷贝呢？其实不然，当Lua发现两个闭包的upvalue指向的是当前堆栈上的相同变量时，会聪明地只生成一个拷贝，然后让这两个闭包共享该拷贝，这样任一个闭包对该upvalue进行修改都会被另一个探知。上述例子很清楚地说明了这点：每次调用f2都将upvalue的值增加了10，随后f1将更新后的值打印出来。upvalue的这种语义很有价值，它使得闭包之间可以不依赖全局变量进行通讯，从而使代码的可靠性大大提高。

    闭包在创建之时其upvalue就已经不在堆栈上的情况也有可能发生，这是因为内嵌函数可以引用更外层外包函数的局部变量：

function Test(n)
   local function foo()
      local function inner1()
         print(n)
      end
      local function inner2()
         n = n + 10
      end
      return inner1,inner2
   end
   return foo
end

t = Test(1979)
f1,f2 = t()
f1()        -- 打印1979
f2()
f1()        -- 打印1989
g1,g2 = t()
g1()        -- 打印1989
g2()
g1()        -- 打印1999
f1()        -- 打印1999

执行完t = Test(1979)后，Test的局部变量n就“死”了，所以当f1,f2这两个闭包被创建时堆栈上根本找不到n的踪影，这叫它们如何取得n的值呢？呵呵，不要忘了Test函数的n不仅仅是inner1和inner2的upvalue，同时它也是foo的upvalue。t = Test(1979)之后，t这个闭包一定已经把n妥善保存好了，之后f1、f2如果在当前堆栈上找不到n就会自动到它们的外包闭包(姑且这么叫)的upvalue引用数组中去找，并把找到的引用值拷贝到自己的upvalue引用数组中。仔细观察上述代码，可以判定g1和g2与f1和f2共享同一个upvalue。这是为什么呢？其实，g1和g2与f1和f2都是同一个闭包(t)创建的，所以它们引用的upvalue(n)实际也是同一个变量，而刚才描述的搜索机制则保证了最后它们的upvalue引用都会指向同一个地方。