Lua发展史

Lua发展史
plainroc翻译 [博客：http://hi.baidu.com/better_and_better]
原文：The Evolution of Lua 链接：www.lua.org/doc/hopl.pdf
译文的原文链接：http://hi.baidu.com/better_and_better/blog/item/1a87d5efc76ccf3dacafd5ff.html

上一篇：3、史前史 http://hi.baidu.com/better_and_better/blog/item/993b8d13711cac8b6538dbfc.html

4. 诞生
SOL小组在1993年3月就实现了一个初步的版本，但是他们从未发布过它。因为PGM很快就要求提供过程式的编程能力，以便创建更复杂的布局，所以SOL不得不进行新的扩充。同时，如前所述，ED的用户们也要求DEL变得更加强大。ED本身也需要为用户界面编程而提供更强的描述能力。大约1993年中期，Roberto、Luiz Henrique和Waldemar聚在一起讨论DEL和SOL。他们得出结论认为，这两种语言可以被一个统一的更强大的语言所代替，他们于是决定动手设计并实现之。Lua团队由此诞生，这个团队直到现在也未曾变动。
鉴于ED和PGM的需求，我们认为，我们所需要的这种语言应该是一个真正的完整的编程语言，它要有赋值语句、控制结构、子程序……等等特性，还需要提供SOL所提供的那种数据描述能力。此外，由于许多潜在用户并不是专业的程序员，所以这种语言在设计时应避免晦涩的语法或语义。考虑到Tecgraf的客户们正在使用的计算机平台多种多样，新语言的实现还必须具有很好的跨平台性。最后，我们预计其他Tecgraf产品也将需要嵌入式的脚本语言，所以新语言的解释器应该遵循SOL的做法，作为一个输出C风格API的库来提供。
当时，我们首先想的是，也许我们可以直接选用一个现成的脚本语言而不是创建一个新的。到1993年为止，唯一真正可能的候选者是Tcl[40]，这是一个明确为嵌入式应用而设计的语言。然而，TCL的语法风格比较少见，也没有提供对数据描述的良好支持，而且还只能在Unix平台上运行[译者注14]。LISP和Scheme是因为不够友好的语法而不在我们的考虑之列。Python则是因为当时仍处于初期阶段而没有入选。综合以上种种，加上当时在Tecgraf里主流的自力更生氛围，我们很自然的就决定，应该努力开发一种自己的脚本语言。因此，我们开始开发一个新的语言，并且希望它比现有的语言都更加易用。我们最初的设计原则是：语言本身要简单、小巧，解释器的实现则应该简单、可移植。由于新语言的部分灵感来自于SOL（其在葡萄牙语中意为“太阳”），所以在Tecgraf的一个朋友（Carlos Henrique Levy）推荐了“Lua”这个名字（在葡萄牙语中，“Lua”意为“月亮”），于是Lua终于诞生。（DEL并未以一种语言的角色对Lua产生多大的影响，其在Lua诞生过程中的主要作用更多的是一种来自于实践的认识：复杂应用程序中的大部分逻辑完全可以用嵌入式的脚本语言来写。）
鉴于我们想要的是一种轻量级的带有数据描述能力的完整语言，所以，我们采用了SOL中record和list[译者注15]的构造语法（但语义上已经没有类型申明的含义了），并用“table”（就是前述的Lua表）来统一了它们的实现方式：record使用字符串（字段名）为索引，list则使用数字索引。一个如下例的赋值语句
T = @track{ y=9, x=10, id="1992-34" }
在SOL中是合法的，在Lua中依然合法，但含义有所不同，在Lua中它表示首先创建一个对象（此处就是表对象），这个对象拥有给定的键y、x、id和指定的键值，然后调用一个名为“track”的函数，参数就是刚才创建的表对象，该函数可能会验证一下参数的有效性或者为某些键填充默认值。该表达式的最终值就是处理后的表对象[译者注16]。
除了这种程式化的数据描述构造语法，Lua并没有发明什么新概念，因为Lua是因为真实的产品需求而生，并非为了研究编程语言本身而设计的学术语言。所以，我们直接借用（有时甚至是不自觉地使用）那些在其他语言中见过或者阅读过的东西。我们并未重读相关论文来查阅所有现存语言的细节，而是直接在对其他语言已有的知识基础上开始工作，并根据我们的口味和需求来进行改造。
我们迅速敲定了一个核心的控制结构集合，其语法几乎完全借用自Modula，包括while、if和repeat until。多重赋值是借用自CLU，多重返回值则是从函数式语言中拿来的。我们认为多重返回值是一个很好的特性，它可以替代Pascal和Modula中使用的引用型参数，也可以替代Ada中使用的输入输出型参数，还可以避免显式的指针（在C语言中使用）。从C++中，我们借用了一个不错的想法：允许一个局部变量在真正被需要时才申明。从SNOBOL和Awk中我们拿来了关联数组，不过改称为“表”，但是在Lua中，表是一个值对象，而不是Awk中那样绑定到变量[译者注17]。
Lua的少数(并且也很小的)创新之一是字符串连接语法。在Lua中，最自然的“+”操作符用于连接字符串会产生歧义，因为我们期望在算术运算中能够自动隐式的把字符串转换为数字。所以我们发明了“..”（两个英文句号）符号来作为字符串连接运算符。
分号的使用是一个具有争议的语法。我们认为，强制使用分号可能给具有Fortran语言背景的工程师造成困惑，而不使用分号则又容易给C语言或Pascal语言背景的人带来混乱。在典型的委员会决策方式下，我们最终设定分号语法为可选[译者注18]。
最初，Lua有7种数据类型：数字（仅实现为实数），字符串，表，空类型，用户数据类型（指向C对象的指针），Lua函数和C函数。为了保持语言的小型化，我们起初并没有包括boolean类型，而是像在Lisp中做的那样，以nil表示假，任何其他值都表示真[译者注19]。超过13年的不断演变，Lua中数据类型方面仅有的变化就是从Lua3.0(1997)起把Lua函数类型和C函数类型统一为了一个单一的函数类型，并且在Lua 5.0（2003）中引入了布尔和协程两种类型（参见6.1节）。为简单起见，我们选择使用动态类型，而不是静态类型。对于需要类型检查的应用程序，我们使用内建函数的方式提供了基本的反射机制，例如运行时类型信息获取和全局环境遍历等。
到1993年7月，作为一个课程项目，Waldemar已经在Roberto的督导下实现了Lua的第一个版本。该实施奉行的宗旨现在已经成为极限编程的核心思想，即是：“the simplest thing that could possibly work”（大道至简）[译者注20][7]。该实现中，词法扫描器和词法解析器是分别用lex和yacc这两个Unix下经典的小型语言实现工具来生成的。解析器负责把Lua源程序转换为一个基于堆栈的虚拟机指令序列，之后这个指令序列可以送到一个简单的解释器上执行。C语言API使得向Lua中添加新的功能变得很容易，因此这第一个实现版本只提供了一个很小的包含5个内建函数（next，nextvar，print，tonumber，type）的标准库，另加三个小型的扩展库（输入输出库，常用数学函数库，字符串处理库）。
尽管这个实现非常简单——但是可能正是因为它——Lua的成功超出我们的预期。PGM和ED都很成功的应用了Lua（PGM目前仍在使用，ED则已经被替换为EDG，后者几乎完全使用Lua写成）。Lua在Tecgraf的迅速成功使得其他的项目也开始使用它。Lua在Tecgraf的初步应用已经结成报告，发表在1993年10月的第七届巴西软件工程研讨会上[29]。
本文的剩余部分主要是关于我们改进Lua的过程的。
（待续）
--------------------------------------------------------------------------------
[译者注14] 目前(2010年初)的Tcl已经是可以在windows等多平台上运行的了。
[译者注15] 之前我曾经把record翻译为“记录”，但是这种翻译容易让人跟数据库中的“记录”搞混，虽然他们在概念上有很大的相似性，但是此文中的record指的是一种字段索引式的数据结构；之前我也把list翻译为“列表”，因为此文中的list并非是通常数据结构中的链表，但是“列表”一词也难以表达出文中所说的list，此文中的list更像是我们通常所说的数组，是一种整数索引的线性容器。所以，我打算不再翻译这两个单词，而保留英文。以后合并为一篇完整的翻译时我会把之前翻译中的“记录”和“列表”改回英文方式。
[译者注16] 此处的说法似乎有些不妥。在SOL中应该确实是返回前面说的那个新建表对象，但是在Lua中表达式返回什么则无法确定，这要看Track函数返回什么，之前创建的表仅仅是作为参数传入track，它完全可能返回另一个完全不同的东西。
[译者注17] 没有学习过Awk，此处原文是not attached to variables as in Awk.可能把attach翻译为“绑定”并不很合适。
[译者注18] 分号作为语句结束符的语法对于解释器而言是很好的，能够有效的避免各种微妙的歧义。Lua虽然设定为可选，但是在某些情况下不使用分号依然会造成歧义，此时分号还是必要的。
[译者注19] 虽然现在加入了布尔类型，但是为了兼容，数字0也依然表示真，因为数字0并不是nil。这可能给很多C程序员带来了极大的困惑。
[译者注20] 原文似乎是缺了一个“Do”，直译是“做可以使之工作起来的最简单的事情”，不过从意思上讲，我个人认为中国的成语“大道至简”作为翻译更贴近，并且更符合“大道至简”的精神。