LL分析法主要由分析栈、分析表和一个驱动算法组成。其实LL的分析算法还是很容易懂的，
主要就是一个匹配替换的过程。而要构造这里的分析表，则还涉及计算first集和follow集
的算法。

个人觉得龙书在解释这些算法和概念时都非常清楚细致，虽然也有人说它很晦涩。

first集和follow集的计算，抛开书上给的严密算法，用人的思维去理解（对于compiler
compiler则需要用程序去构造这些集合，这是让计算机去理解），其实很简单：

1、对于某个非终结符A的first集（first(A)），简单地说就是由A推导得到的串的首符号的
集合：A->aB，那么这里的a就属于first(A)，很形象。
2、follow(A)，则是紧随A的终结符号集合，例如B->Aa，这里的a就属于follow(A)，也很形
象。

当然，因为文法符号中有epsilon，所以在计算上面两个集合时则会涉及到一种传递性。例
如，A->Bc, B->epsilon，B可以推导出epsilon，也就是基本等同于没有，那么first(A)中
就会包含c符号。

在了解了first集和follow集的计算方法后，则可以通过另一些规则构造出LL需要的分析表。

编译原理里总有很多很多的理论和算法。但正是这些理论和算法，使得编译器的实现变得简
单，代码易维护。

在某个特定的编程语言中，因为其文法一定，所以对于其LL(1)实现中的分析表就是确定的
。我们也不需要在程序里动态构造first和follow集合。

那么，要实现一个LL(1)分析法，大致步骤就集中于：设计文法->建立该文法的分析表->编
码。

LL分析法是不能处理左递归文法的，例如：expr->expr + term，因为左递归文法会让对应
的分析表里某一项存在多个候选式。这里，又会涉及到消除左递归的方法。这个方法也很简
单，只需要把文法推导式代入如下的公式即可：

A -> AB | C 等价于：A -> CX, X -> BX | epsilon

最后一个问题是，如何在LL分析过程中建立抽象语法树呢？虽然这里的LL分析法可以检查文
法对应的语言是否合法有效，但是似乎还不能做任何有意义的事情。这个问题归结于语法制
导翻译，一般在编译原理教程中语法分析后的章节里。

LL分析法最大的悲剧在于将一棵在人看来清晰直白的语法树分割了。在递归下降分析法中，
一个树节点所需要的属性（例如算术运算符所需要的操作数）可以直接由其子节点得到。但
是，在为了消除左递归而改变了的文法式子中，一个节点所需要的属性可能跑到其兄弟节点
或者父节点中去了。貌似这里可以参考“继承属性”概念。

不过，综合而言，我们有很多业余的手段来处理这种问题，例如建立属性堆栈。具体来说，
例如对于例子代码中计算算术表达式，就可以把表达式中的数放到一个栈里。

例子中，通过在文法表达式中插入动作符号来标识一个操作。例如对于文法：
expr2->addop term expr2，则可以改为：expr2->addop term # expr2。当发现分析栈的栈
顶元素是'#'时，则在属性堆栈里取出操作数做计算。例子中还将操作符压入了堆栈。

下载例子，例子代码最好对照arith_expr.txt中写的文法和分析表来看。

PS，最近在云风博客中看到他给的一句评论，我觉得很有道理，并且延伸开来可以说明我们
周围的很多现象：

”很多东西，意识不到问题比找不到解决方法要严重很多。比如one-pass 这个，觉得实现
麻烦不去实现，和觉得实现没有意义不去实现就是不同的。“

对于以下现象，这句话都可以指明问题：
1、认为造轮子没有意义，从不考虑自己是否能造出；
2、常告诉别人某个技术复杂晦涩不利于团队使用，却并不懂这个技术；
3、笼统来说，【觉得】太多东西没有意义，虽然并不真正懂这个东西。

我只不过不想在工作若干年后还是一个只会打字的程序员。学点什么东西，真正精通点什么东西才对得起喜欢

技术的自己。

附件中的代码粗略实现了《编译原理》龙书中的几个算法。包括解析正则表达式，建立NFA，然后用NFA去匹

配目标字符串；或者从NFA建立DFA，然后匹配。解析正则表达式我用了比较繁琐的方法，有词法和语法分析

过程。词法分析阶段将字符和一些操作符整理出来，语法分析阶段在建立语法树的过程中对应地建立NFA。

当然，因为语法树在这里并没有用处，所以并没有真正地建立。

从正则表达式到NFA比较简单，很多编译原理书里都提到过，如：s|t表达式对应于下面的NFA:

代码中用如下的结构描述状态和状态机中的转换：

#define E_TOK (0)

/* transition */
struct tran
{
    char c;
    struct state *dest;
    struct tran *next;
};

struct state
{
    /* a list of transitions */
    struct tran *trans;
    /* inc when be linked */
    int ref;
};

即，每一个状态都有一个转换列表，每个转换都有一个目标状态（即该转换指向的状态）以及转换字符。

貌似通过以上方法建立出来的状态机每个状态最多只会有2个转换？

建立好NFA后，由NFA匹配目标字符串使用了一种构造子集法（《编译原理》3.7.2节）：

这个算法里针对NFA的几个操作，如e-closure、move等在由NFA转换DFA时也被用到，因此代码里单独

做了封装（state_oper.c）。这个算法本质上貌似就是一次步进（step）多个状态。

至于由NFA转DFA,则是相对简单的子集构造法：

在我以前编译原理课考试的前一天晚上（你懂的）我就对这些算法颇为疑惑。在以后看各种编译

原理教材时，我始终不懂NFA是怎么转到DFA的。就算懂了操作步骤（我大学同学曾告诉我这些步骤，虽然

不知道为什么要那样做），一段时间后依然搞忘。很喜欢《编译原理》龙书里对这个算法最本质的说明：

源代码我是用GCC手工编译的，连makefile也没有。三个test_XXX.c文件分别测试几个模块。test_match.c

基本依赖除掉test外所有c文件，全部链接在一块即可。当然，就经验而言我知道是没几个人会去折腾我的这些

代码的。这些在china的领导看来对工作有个鸟用的代码读起来我自己也觉得费力，何况，我还不伦不类地用了

不知道算哪个标准的c写了这些。

你不是真想下载。对于这种代码，有BUG是必然的，你也不用在此文若干个月后问我多少行是什么意思，因为

那个时候我也忘了:D。

    之前我一直说错误处理是kl里的软肋，由于一直在关注一些具体功能的改进，也没有对
这方面进行改善。

    我这里所说的错误处理，包括语言本身和作为库本身两方面。
    语言本身指的是对于脚本代码里的各种语法错误、运行时错误等的处理。好的处理应该
不仅仅可以报告错误，而且还能忽视错误让处理过程继续。
    而把kl解释器作为一个库使用时，库本身也应该对一些错误情况进行报告。

    整体上，kl简单地通过回调函数指针来把错误信息传给库的应用层。而因为我希望整个
kl实现的几层（词法分析、语法分析、符号表、解释器等）可以尽可能地独立。例如虽然语
法分析依赖于词法分析（依赖于词法分析提供的接口），但是因为词法分析并不对语法分析
依赖，所以完全可以把词法分析模块拿出来单独使用。所以，在日志方面，我几乎为每一层
都附加了个error_log函数指针。
    而用户层在通过kllib层使用整个库时，传入的回调函数会被间接地传到词法分析层。
实际上，当kl作为一个库时，kllib正是用于桥接库本身和用户层的bridge。

    另一方面，语言本身在处理错误的脚本代码时，错误分为几大类型层次：
    1.词法错误 lex error，如扫描字符串出错
    2.语法错误 syntax error，整理语法树时出错
    3.运行时错误 runtime error，在解释执行代码时出错
    4.库错误 lib error，发生在kllib这个bridge层的错误
    kl在报告错误信息时，会首先附加该错误是什么类型的错误。

    这里最麻烦的是语法错误的处理。因为语法分析时发生错误的可能性最大，错误类型也
有很多。例如你少写了分号，少写了括号，都会导致错误。这个阶段发生错误不仅要求能准
确报告错误，还需要忽略错误让整个过程尽量正确地下去。

    语法分析阶段最根本的就是符号推导（单就kl的实现而言），所谓的符号推导是这样一
个过程，例如有赋值语句：a = 1;语法分析时，语法分析器希望（所谓的推导）等号后面会
是一个表达式，当分析完了表达式后，又希望接下来的符号(token)是分号作为该语句的结
束。
    所以，klparser.c中的syn_match正是完成这个过程。每次你传入你希望的符号，例如
分号，该函数就检查词法分析中当前符号(token)是否是分号。当然，对于正确的脚本代码，
它是一个分号，但是如果是错误的代码，syn_match就会打印诸如：
    >>syntax error->unexpected token-> ....
    即当前的符号是不被期望的。

    上面完成了错误的检测。对于错误的忽略，或者更高级点地对错误的校正，kl中处理得
比较简单，即：直接消耗掉这个不是期望中的符号。例如：
    a = 1 /* 忘加了分号 */
    b = 1;
    上面两句代码被处理时，在处理完a=1后，发现当前的符号(token)b(是一个ID token)不
是期望(expect)中的分号，首先报告b不是期望的符号，然后kl直接掠过b，获取下个符号=。
然后处理a=1这个过程结束。当然，下次处理其他语句时，发现=符号，又会继续发生错误。

    错误信息中比较重要的还有行号信息。之前kl这方面一直存在BUG，我在写贪食蛇例子
的时候每次新加代码都不敢加太多。因为解释器报告的错误行号总是错误的，我只能靠有没
有错误来找错误，而不能通过错误信息找错误。
    行号信息被保存在词法分析状态中(lexState:lineno)，语法分析中获取token时，会取
出当前的行号，保存到语法树树节点中。因为包括解释模块都是基于树节点的，所以词法分
析语法分析解释器三层都可以准确报告行号。

    但是之前解释器报告的行号始终很诡异。症结在于我在载入脚本代码文件时，以rb方式
载入，即二进制形式。于是，在windows下，每行文本尾都会有\r\n两个字符。而在词法分
析阶段对于行号的增加是：
    case '\n':
    case '\r':
        ls->lineno ++;
    不同OS对于文本文件的换行所添加的字符都不一样，例如windows用\r\n，unix系用\n
，貌似Mac用\r。所以，词法分析这里写应该可以准确地处理行号。

    但是对于windows，这里就直接将行号增加了两次，所以也就导致了行号出错的问题。查
了下文档，发现以文本方式打开文件("r")，调用fread函数读入文件内容时，就会自动把
\r\n替换为\n。

    代码改后，又出问题。这个时候，通过fseek和ftell获取到的文件尺寸，貌似包括了
\r\n，而fread出来的内容却因为替换\r\n为\n而没有这么多。
    不过文件载入不属于kl库本身，kl只接收以字符串形式表示的脚本代码，所以也算不了
核心问题。

    同样，最新代码可以从google SVN获取。当然，我也在考虑是否换一个新的项目地址。

    貌似最近CPPBLOG写一门脚本语言比较流行，连我这种山寨程序员都搞出一个像C又像
BASIC的所谓脚本语言，可见其流行程度。

    这个kl脚本例子，是一个具有基本功能的贪食蛇游戏。这个例子中使用了两个插件：
HGE引擎、以及一个撇脚的二维数组插件。因为kl对于数组的实现不是那么漂亮，而我实在
不想因为加入二维数组的支持而让代码看起来更乱，所以直接不支持这个特性。考虑到二维
数组的应用在一些小游戏中还是比较重要（例如这个贪食蛇，总需要个容器去保存游戏区域
的属性），所以撇脚地加了个支持number的二维数组插件。

    HGE插件我只port了部分接口，也就是注册了一部分函数到脚本里，提供基本的贴图功
能。（port--我实在找不到一个合适的词语来形容这种行为---HGE到一门脚本语言里，我似
乎做过几次）

    不知道有没必要提供贪食蛇的实现算法，这似乎说出来有点弱智。- - 不过为了方便别
人阅读kl脚本代码，我还是稍微讲一下。游戏中使用一个二维数组保存整个游戏区域，所谓
的游戏区域就是蛇可以活动到的地方。每一个二维数组元素对应游戏区域中的一个格子，姑
且称为tile。每个tile有一个整数值表示其属性，如BODY、WALL、FOOD、NONE。蛇体的移动
归根结底就是蛇头和蛇尾的移动。蛇头和蛇尾属性一样，但是蛇头负责把所经过的tile设置
为BODY，而蛇尾则把经过的tile设置为NONE。蛇头的移动方向靠玩家控制，每次蛇头转弯时
，都会记录一个转弯点到一个队列。转弯点包括转弯XY坐标以及转向的方向。蛇尾每次移动
时都会检查是否到达了一个转弯点，是的话就设置自己的移动方向为该转弯点记录的方向。

    虽然我写了kl这个脚本语言，但是语言特性并不是我设计的。我只是取了C语言的一些
特性。所以在写这个sample的时候，我对于kl这个脚本语言的感觉，就是一个像basic的C。
因为它太单一，就像BASIC一样只拥有语言的一些基本功能，不能定义复杂的结构，没有天
生的对各种数据结构的支持（例如某些语言直接有list, tuple之类）。

    以前中学的时候在电子词典上用GVBASIC写小游戏，当时除了BASIC什么也不知道。今天
写这个贪食蛇例子，感觉就像以前用BASIC。

    回头说说一些kl脚本里的特性。从这个例子里（见下载包里的snake.kl），诸如while，
for，if...else if...被支持（之前发布的版本里还不支持for和else if）。全局变量支持
赋初值（上个版本不支持）。当然，还演示了如何使用插件函数。

    但是，仍有一些特性在我的懒惰之下被置之不理。例如return后必须跟一个表达式，这
意味着单纯的return;将被视为语法错误。对于if( a && b )，kl会计算所有的表达式，而
别的语言也许会在a会false后不计算b，这也许不算个问题，但起码我还没修正。还有，kl
内部对于错误的报告依然没被修复，少打一个分号你会得到一系列错误的报告，但是却没有
准确的行号。甚至，你会看到解释器崩掉。不要紧，在我心里，它作为当年电子词典上那个
GVBASIC而言，已经很强大的了。:DD

    最近接触了很多UNIX和GNU之类的东西，发觉没有提供版权说明的‘开源’，原来都是伪
开源。虽然我也想按照GNU编码标准里所说为kl的发布包里附加Changelog之类的说明，但是
出于懒惰，还是以后再说吧。同样，这次提供的下载里包含了一些编译好的东西，所以我不
保证它在你的机器上依然可以运行。我使用了MingW来编译这些，并且提供有点丑陋的Makefile。
HGE使用了1.81版本。
    贴张图给懒得下载的人：

    下载例子，包含脚本代码。

    如果要获取kl实现代码，建议从我在google的SVN获取：
http://code.google.com/p/klcommon/

脚本与C语言交互

    这其实是这一系列的最后一篇，因为我觉得没什么其他需要写的了。
    一般而言，脚本语言同C语言交互，包括在C语言中注册C函数到脚本，从而扩展脚本的
功能，以及在C语言中调用脚本函数。
    为了扩展脚本的功能，这里引入插件的概念。kl在这方面大致上实现得和lua相似。kl
支持静态插件和动态插件。
    在C语言中调用脚本函数，kl中提供了一些简单的接口用于满足需求。

静态插件

    静态插件其意思是在C代码中注册函数到脚本中，并随脚本库一起编译链接成最终执行
程序。因为其绑定是在开发一个程序的过程中，所以被称为静态的。
    一个插件函数，指的是可以被注册进脚本的C函数。这种函数必须原型一样，在kl中这
个函数的原型为：typedef struct TValue (*kl_func)( ArgType arg_list );   
    当你定义了一个这样的原型的函数时，可以通过kl库提供的:
    int kl_register( struct klState *kl, kl_func f, const char *name )来注册该
函数到kl脚本中。该函数参数很简单，第三个参数指定注册进脚本中时的名字。

    原理比较简单：在解释器中保存着一个插件符号表，该符号表的符号名就是这个函数提
供的名字，符号对应的值就是第二个参数，也就是插件函数的函数地址。
    解释器解释到函数调用时，先从插件符号表中查找，如果找到符号，就将符号的值转换
为插件函数，并调用之。

    插件函数的参数其实是一个参数链表。脚本里调用插件函数时，所传递的参数将被解释
器整理成参数链表并传递给插件函数。kl库中(集中在kllib.h中)提供了一些方便的接口用
于获取每个参数。
    插件函数的返回值也将被解释器转换为脚本内部识别的格式，并在必要的时候参与运算
。

动态插件

    动态插件同静态插件的运作方式相同，所不同的是动态插件的插件函数被放在动态运行
时库里，例如windows下的dll。
    kl插件编写标准里要求每个动态插件必须提供一个lib_open函数。kl解释器（或者kl库
--当被用作库时）载入一个动态插件时，会直接调用lib_open函数。lib_open函数的主要目
的就是把该插件中的所有函数都注册进脚本里。

    因为动态插件在设计之初没有被考虑，所以我并没有为kl加入一些原生的关键字用于导
入动态插件，例如import、require之类。我在静态插件层次提供了这个功能。即我提供了
一个libloader静态插件，链接进kl解释器程序。该静态插件提供脚本一个名为import的函
数。该函数负责动态载入dll之类的动态库，并调用里面的lib_open函数完成动态插件的注
册。

C程序里调用脚本函数

    这个比较简单，通常C语言想调用一个脚本函数时，会传入脚本函数名。因为脚本函数名
都保存在全局符号表里，kl库从全局符号表找到该函数符号，并转换其值为语法树节点指针
，然后传入解释器模块解释执行。
    kl库提供struct TValue kl_call( struct klState *kl, const char *name, ArgType args );
用于在C里调用脚本函数。

代码导读

    kllib.h/kllib.c作为一个桥接层，用于封装其他模块可以提供给外部模块使用的接口，
如果将kl作为一个库使用，用户代码大部分时候只需要使用kllib.h中提供出来的接口。
    源码目录plugin下的kllibbase.c中提供了静态插件的例子，kllibloader.c提供了装载
动态插件的功能。
    源码目录plugin/hge目录下是一个封装2D游戏引擎HGE部分接口到kl脚本中的动态插件
例子。
    源码目录test/kl.c是一个简单的kl解释程序，它用于执行一段kl代码。这个程序同之前
说的解释器不是同一回事。当我说到解释器时，它通常指的是klinterpret.c中实现的解释
模块，而解释器程序则指的是一个使用了kl库的独立解释器可执行程序。

解释器

    整理出语法树后，我们就可以根据语法树，并配合符号表开始解释执行脚本代码。这就
是接下来要涉及到的解释器。

工作原理

    在第四节中讲语法树时，其实就已经提到解释器的大致工作原理。
    一个kl的hello world例子代码大致为：
    function main()
    {
        print( "hello world\n" );
    }
    在第二节中我描述了kl代码整体上的结构，是以函数为单位的。因此，对于一个完整的
kl脚本代码，其经过语法处理后，将建立一棵大的语法树，该语法树大致结构为：
    fn1_node
        stmt_node1
        stmt_node2
        ...
    fn2_node
        stmt_node1
        stmt_node2
        ...

    fn1_node和fn2_node同属于同一个作用域，fn1_node的sibling指针指向fn2_node，即在
整个树结构中，每一个node通过child[3]成员连接其子节点，通过sibling指针连接其相邻
的节点。   
    解释器解释执行时，就是从main函数所对应的节点开始递归执行的。对于每个节点，都
可以知道该节点对应了哪种程序逻辑：是加法运算、比较运算、还是一些控制语句等等。
    以这样的控制语句举例：
    if( 1 ) print( "true" );
    对if语句而言，其语法树结构为：
          if_node
         /   |    \
        /    |     \
    con_exp    then_stmt else_stmt

    即，if语句有最多有三个子节点(child[3])，child[0]指向if的条件表达式，child[1]
指向条件表达式为真时执行的语句序列，如果if有else部分，那么child[2]就指向else部分
的语句序列。
    那么，在发现某个节点是if节点时，就首先计算其条件表达式节点。这个节点的计算方
式同脚本中其他所有表达式的计算方式相同，当然，它也是一个递归操作。计算完后判断该
表达式的值是否为真，为真则递归执行if节点的child[1]节点，否则检查是否有else节点，
有的话就执行child[2]节点。

    其他所有节点的解释方式都是相同的。

解释器环境

    解释器环境指的是解释器在解释执行脚本代码时，所需要的运行时环境。kl中主要是符
号表信息。一个解释器环境会有三个符号表：全局符号表，主要保存全局变量以及脚本函数
符号；函数局部符号表，在解释调用一个脚本函数时，会建立临时的符号表；插件符号表，
用于保存插件注册的函数。

如何解释执行函数

    函数主要有两大类型：脚本内定义的函数以及插件注册进符号表的函数。无论是哪种函
数，都会在符号表中建立对应的符号。对于前者，符号被保存于全局符号表，其保存的内容
是该函数节点的节点指针；而对于后者，则保存的插件函数的函数地址值。

    每一次解释器解释到一个函数调用节点时，会优先在插件符号表中查找该函数符号。如
果找到，就将其值转换为约定的插件函数类型（如同lua里注册的C函数一样），然后整理参
数调用之。这个时候代码执行权转接到插件函数里。如果没找到，就在全局符号表里查找，
找到后就强转为语法树节点指针，并解释执行该节点下的语句。

代码导读

    解释器的代码位于klinterpret.h/klinterpret.c中。整体上而言没什么特别的地方，
主要是利用语法树的特点。
    完成了这一节后，kl就已经可以解释执行所有的脚本语句。当然，因为没有输出功能，
只能在调试器里看看计算结果。下一节里会讲到将脚本结合进C语言，从而可以让C语言注册
所谓的插件函数到脚本里，也就可以让脚本具有print这样的输出函数。

符号表

    在上一节中，当我们的解释器解释执行age=age+1这个语法树时，会涉及到变量age的值
。实际上我们还需要个保存脚本中相关变量的模块，当我们的解释器获取到一个ID树节点时
，需要从这个模块中获取出该变量的值，并参与运算。
    这个我称之为符号表。我想到这里，我所说的概念很可能和教科书有点不一样了。

什么是符号表？

    符号表(symbol table)就如同其字面意思一样，是一个表，更宽泛地说是一个保存符号
的容器。
    脚本中诸如变量函数之类的东西都算作符号，例如age。符号表就是保存这些符号的容
器。
    在kl中，符号表保存着某一个作用域里的变量。其全局符号表还保存着函数符号，对于
函数符号而言，其值为语法树树节点的指针值。当调用一个函数时，将该值转换为树节点，
然后执行。当然，这应该算做解释执行一节的细节，不多说。

    再明确下符号表的作用，举例，在上一节中，涉及到这么一个例子函数：
    value factor( TreeNode *node )
    {
        switch( node->type )
        {
            case ID:
                /* 在这里，发现一个树节点类型为ID，就需要根据ID对应的名字，也就
                 是age，在符号表中查找age的值 */
                return age；   
        /* ... */
        }
    }
    以上注释阐述了符号表的作用。

符号表的实现

    其实不管符号表如何实现，对于其他模块而言，对符号表的唯一要求就是提供几个类似
这样的接口：
    value sym_lookup( const char *name );
    void sym_insert( const char *name, value val );
    也就是说，提供查找符号值，以及插入新符号的接口。

    在kl中，使用了<编译原理与实践>中相同的符号表数据结构实现。即使用了hash表，
hash数组中每个元素保存的是一个链表头节点。每一个符号字符串通过散列函数得到hash数
组索引，然后在该索引里进行一次线性查找。很典型的hash结构。

    另一方面，因为kl支持全局和函数局部两个作用域。所以kl中有一个全局符号表，用于
保存全局变量以及所有的函数符号；同时每一次进入一个函数时，就会创建一个临时的局部
符号表，用于存储局部变量；后来，为了支持插件，插件函数被特定地保存在另一个全局符
号表里。

代码导读

    kl中的符号表实现代码在klsymtab.h/klsymtab.c中，实现比较简单，无需多言。

语法分析

    语法分析接收词法分析阶段的token集合为输入，将这些没有关系的tokens整理为相互
之间有关系的结构。书面点的说法叫语法树。
    每一次让我写这些文绉绉的概念真让我受不了:D。

语法树

    语法树简单来说就是一个以token作为每个节点的树型结构。例如我们有表达式age =
age + 1;，在词法阶段它被整理为token集合：age, =, age, +, 1。那么在经过语法分析后
，这些tokens将被整理为大致如下的树形结构：
        =
      /   \
    age    +
         /   \
       age     1

    整理成这样的结构有什么好处？就kl解释器而言，最直接的好处就是我可以递归地解释
这棵树执行。例如：

    value compute( TreeNode *root )
    {
        /* child[0]保存结果值age，child[1]是那个+表达式 */
        return op_exp( root->child[1] );
    }

    value op_exp( TreeNode *node )
    {
        switch( node->op )
        {
            case '+':
            {
                /* + 表达式必然有左右操作数 */
                value left = factor( node->child[0] );
                value right = factor( node->child[1] );
                return left + right;
            }
        }
    }
    value factor( TreeNode *node )
    {
        switch( node->type )
        {
            case ID:
                /* 查找age的值 */
                return age;

            case CONST:
                /* 1 是常量 */
                return node->cvalue;
        }
    }

    如你所见，当我们完成了语法分析阶段，我们就可以完成我们的解释器了。后面我会单
独讲解下整个解释过程，包括每个模块是如何协作的。我不知道其他解释器是怎么做的，但
是我这样做，起码结果是对的。

如何整理出语法树？

    这里不得不提到所谓的BNF文法，很明显你还是无法从我这里获取编译原理里某个概念
的讲解。我这里提这个概念完全是方便我提到这个东西。
    每一种语言都有其自己的BNF文法，因为万恶的先知告诉我们，每一门语言都需要建立
其语法树。- -!
    就像词法分析一样，因为大部分语言的结构都差不多，所以我觉得词法分析和语法分析
基本上都没有任何特别之处。也就是说，别的语言的BNF你可以直接拿来改改用。
    抄个BNF如下：
    exp -> exp adop term | term
    addop -> + | -
    term -> term mulop factor | factor
    mulop -> *
    factor -> (exp) | number
    这个BNF用来描述一般的算数表达式(+-*/)。简单来说，一门语言的BNF就是用于描述该
语言所有语句的东西，包括if、while、函数定义之类。建议你google一下C语言的BNF，并
改造之用于你自己的语言。

    那么有了BNF之后，该如何整理出语法树呢？
    通常，我们的代码里都会直接有对应exp、term、addop之类的函数。按照我这句话的意
思，上面抄的BNF被翻译为程序代码后，就可能为：
    exp()
    {
        if( ... ) left = exp()
        right = term();
        left addop right;
    }
    term()
    {
        if( ... ) left = term()
        right = factor();
        left mulop right;
    }
    factor()
    {
        if( ... ) return exp();
        else return number;
    }

    (可能还会涉及到EBNF，用于处理重复和选择的一些情况---不用管这句话)

    每一个函数基本上都会返回一个树节点，当然，该节点下可能会有很多子节点。   

总结

    语法分析基本上就是以上信息。它将词法分析输出的token集合整理成一颗语法树。为
了整理出这棵语法树，你需要找一份用于描述你语言的BNF，然后根据BNF翻译成处理代码。

代码导读

    kl中的整个语法分析代码位于klparser.c/klparser.h中，其BNF基本上取自<编译原理与
实践>附录中的C_语言。

词法分析

    词法分析属于整个编译流程中的第一个阶段。为什么要把编译过程分为多个阶段，这就
如同软件分层一样，个人觉得是出于降低复杂性的考虑。
    再次声明我不会告诉你任何编译原理的理论知识，因为坦率地说我也不会:D。所以我努
力将我们需要了解的概念尽可能简单地告诉你。当然，可能会与教科书不吻合。

什么是词法分析?

    词法分析就是把一段话整理成单词集合。举个简单的例子，例如有代码:age = age + 1;，
经过词法分析后，将得到：age、=、age、+、1、;几个符号。为了方便，我称每个单词为一
个token。

词法分析的作用

    词法分析分析出来的单词集合，直接作为编译流程中接下来的语法分析的输入。那么语
法分析阶段面对的将是一个一个的token，而不是单个的字符。
    例如，在处理age = age + 1;这种语句时，当我们获取到token "="时，我们直接期望接
下来的token应该是个表达式。以单词为单位地处理，比直接处理单个字符简单很多。

词法分析的过程

    词法分析的输入是单个字符流，一般我们fopen一个源代码文件，保存在一个char缓存
里，这就是词法分析的输入。而词法分析的最终输出结果就是一个一个的token。
    为了处理方便，token并不是单纯的单词。通常我们会将源代码中的所有单词分类，例
如变量名其实都属于一类token。简单的token可定义为：
    struct Token
    {
        int type;
        char value[256];
    };
    type用于表示token的类型，例如一个变量名token的类型是一个标识符。value可以用
来具体地保存这个变量的名字。

    对于type的处理，通常会事先定义一组枚举值，例如：
    enum    {    ID, NUM, STRING, IF, ELSE, WHILE, RETURN, FUNCTION }等等用于标示
在一个源代码中可能出现的所有token。

    虽然说词法分析的结果是一个token集合，但事实上我们并不是一次做完词法分析。通常
词法分析模块提供一个get_token函数。每次调用该函数时，都返回源代码中下一个token。
例如，有源代码：age = age + 1;
    第一次调用get_token将获得 { ID, "age" }，第二次获得 { ASSIGN, "=" }，第三次
获得{ ID, "age" }，等等。

    那么，词法分析该如何实现？也就是struct Token get_token()函数如何实现？其实很
简单，你告诉我：给你一个字符串，你如何判断这个字符串全部是数字？
    int is_num( const char *str )
    {
        while( *str != 0 )
        {
            if( !isdigit( *str++ ) ) return 0;
        }
        return 1;
    }
    所以，基本上，词法分析的过程也就是这个过程。就拿标识符举例，典型的标识符一般
以字符开头，然后接着是数字或字符或_，当遇到非法字符时，这个标识符的扫描即结束。
    词法分析一般是个while+switch：
    struct Token get_token()
    {
        while( current_char != 0 )
        {
            switch( current_char )
            {
                case CHARACTER:
                    /* 扫描一个标识符 token */
                    break;

                case '=':
                    /* 获得一个 ASSIGN token */
                    break;

                    ...
            }
        }
    }

    现在，试着去总结一门语言里的每一个token的规则，然后自己去写写看。

代码导读

    在本节我将提供kl在googlecode的SVN上的代码，先不要去管代码包中的其他东西。关于
词法的代码可以在kllex.c kllex.h中找到。lex_token是提供给其他模块的接口，用于获取
当前扫描的token。扫描结果可以通过lexState结构体获取。
    再次提下版权问题，代码文件以及代码包中我并没有加入任何版权说明，哪怕是GPL。
但是如同我之前说的一样，我不介意你传播、改动此代码，但是请保留原作者信息。当然，
我并不介意你加上@modified by xxx:)。

    下载kl源代码：http://klcommon.googlecode.com/files/kllan_0.1.0.zip

语言特性

    在正式讨论实现细节前明确下这个脚本语言的一些语言特性，基本上可以让我们预见将
来会遇到哪些难题。总的来说，它（脚本）将同我们平时接触的如lua一样的脚本语言：拥
有一般的编程语言特性，如变量、各种控制流程、也许还有函数，另一方面它还应该和它的
宿主语言结合，如作为一个库被用进C，这还涉及到给这门语言设计一种插件方式，最好能
通过独立的解释程序让脚本载入一些插件运行。

    以下在描述我写的这个脚本语言时，将以kl表示它的名字，以方便描述。

代码块：

    首先从整体风格上，kl如同C语言一样被划分为函数块，如：
    function func1()
    {
    }
    function func2()
    {
    }
    ...
    kl支持以{}隔离代码块，但是这并不意味着kl有多个独立的局部堆栈，如同C语言一样。
这些细节暂不讨论。本节描述的所有内容你都不必深究，因为我只要求你对kl有个感性上的
认识。
    函数块之外没有可执行的语句(statement)。那么你可能会想到程序的入口点也许会是
main。事实上从kl提供的库来看，并没有这种硬性要求。但是，kl的独立解释程序是这样要
求的。   

变量：

    kl允许你在任何地方使用一个变量。变量不需要事先定义，任何地方出现一个合
法的标识符时，就意味着kl内部会增加这个变量，并给予初值。变量也没有静态类型，也不
会固定为某一类型。就一门最简单的语言来看，我觉得数据类型无非就是字符串和数字类型
。
    所以，kl的变量在某一时刻必然是数字，或者字符串。在脚本里，你无法获知一个变量
的类型，事实上也没这个必要。说变量拥有一个类型属性，倒不如说值(value)有一种类型
属性。
    当字符串值与数字值参与运算时，如1+"a"，其运算结果将自动转换为字符串，也就是
"1a"。
    一个只有标识符的语句(statement)通常意味着你想定义一个变量。这种无聊的手段通
常被用于定义全局变量。

运算符：

    kl支持一般的C语言风格的算术、比较、逻辑运算符。例如加减乘除、大于小于、逻辑
与逻辑或。

作用域：

    kl脚本里只有两个作用域：全局的和局部的。
    位于所有函数块外的变量处于全局作用域；位于函数内的变量处于局部作用域，位于函
数块内的代码块变量，还是处于局部作用域。
    当局部作用域内出现一个全局里的同名变量时，优先取局部作用域里的变量。这同C语
言一样。

控制语句if：
    if的语法同C语言一样，如：
    if( a > 10 )
    {
    }
    else
    {
    }
    if( a > 10 )中的a>10被我成为条件语句，所有条件语句，包括下面的while，都不能
为字符串。例如if( "a" )将被视为非法语句。（我为什么要这样考虑？- -!）

控制语句while:

    c-like while:
    while( a > 10 )
    {
    }
    很遗憾，我暂时没有加入对for的支持。因为我觉得既然有了while，有了循环控制，在
没有更多无聊时间的前提下，我没有必要加入for。

函数：

    很遗憾，函数的定义和调用和C语言有点不一样。这是因为kl没有变量类型，那就意味
着函数定义如果和C语言一样，就会出现语法歧义，如：
    func( a )
    {
    }
    就会和函数调用func(a)出现混淆。所以，我加入了function关键字。定义函数的语法
为：
    function func( a, b )
    {
    }
    如你所见，函数支持参数传递，当然也支持return a;返回值。kl是简陋的，因为它没
有指针之类的概念，所以你无法为函数传递一块数据。当然，kl也不能像lua一样让函数可
以返回多个值。
    函数调用的语法相对熟悉：
    func( 1, 3 );

数组：

    从一开始我就没考虑为kl加入数组。事实证明加入数组是一个不明智的做法。数组的支
持让代码在很多地方变得脏乱。无论如何，kl后来支持一维数组了。为了让代码保持那么一
点点的干净，我甚至为定义数组加入dim的关键字。这意味着，在kl里，数组和一般的变量
总有点不一样：变量无需定义，数组却必须事先定义。
    数组的长度不支持动态扩充。如果支持，我得让kl内部更好地去管理内存。
    数组元素的类型没有硬性的规定，这意味着a[0] = 1; a[1] = "a";是允许的。

    语言特性上就描述这些，在本节末尾我决定贴一段kl计算阶乘的代码：

/* fac.kl */
function main()
{
    n = input( "%d" );
    print( "fac(" + n + ") = " + fac( n ) );
}

function fac( n )
{
    if( n == 1 )
    {
        return 1;
    }
    else
    {
        return fac( n - 1 ) * n;
    }
}

    （相信我，这一节全是废话。）
    我不是标题党，但是有必要解释下这个标题。综合来说我就是想与你分享我所学到的。
我会将我实现的这个简单的脚本语言的实现细节展示给你。它将涵盖：词法分析、语法分析
、符号表管理、语法树解释执行、插件管理等内容。
    我并不擅长传授编译原理知识。我没有听过编译原理课，所以我也不会编译原理（也许
即使我听了也不会:D）。所以对于这方面的能手而言，我口中的‘DFA‘可能会贻笑大方。
    显然，CPPBLOG上有编译原理上的大牛。如果你想学习更深入的知识，可以去请教他们。
vczh(http://www.cppblog.com/vczh/) 看起来是我所说的这个人。在致谢名单里我将真诚地
写上他的名字。他的’手把手xxx脚本‘系列多多少少还是给了我一些有用的信息。
    其次是FOX，在词法分析的DFA和NFA那里我请教了他一些问题。虽然我现在又忘了。如
你们所知，理论和实现之间总会隔着鸿沟。

    推荐《编译原理与实践》(<Compiler Construction:Principles and Practice>
Kenneth C. Louden)这本书。在你将来阅读我的脚本语言的实现代码时，你会发现有很一些地
方同这本书里的TINY语言实现代码有相似之处。建议你阅读TINY的代码。
    感谢VIM、GCC、GDB、MingW，我用这些软件在工作之余写出了这个东西的几千行C代码。
很明显我是个开源文化的爱好者。但是我不会告诉你unix有多么多么好，因为我也是个初学
者，我还不懂unix。开源在我看来更是一种分享知识的精神。让这种精神如同GPL一样病毒
式地传染下去。
    还有版权问题。但也许它不是个问题。我不会添加任何版权信息。我允许你任意传播、
改动我所散播的东西，但是唯一的基本条件是：保留作者的信息---不要告诉别人，这东西
是你做的。

    在所有的文章发布后，我都可能会再次修改。也许通过RSS或者日志日期之类你可以获
得修改提醒。

附上全部源代码（对于代码我还是比较满意的:D），下载