• 把「两个」代码生成器合并了不少，主要是表达式的部分。原来 LFC 里，非阻塞的函数和连续体的代码生成器是分开的，然而很多段代码都大同小异（就是 transform 和 expPart 的区别，这两个函数都是进行递归变换的函数，不过行为不同），现在合并了。
• 现在的 LFC 里，全局变量必须手工指定，以后会简化设置它的方法，比如允许 JavaScript 全局变量直接绑定到 lofn 的顶层函数里
• 文档这个巨坑慢慢填罢

顺便贴个东西：用源码的面积计算 pi 复刻版：

var c = 0; var l = 0
def x(n) = (c += (2 if (n == x), 1)) then (l = n if(l < n), l) then (n + 1)
def x.valueOf = {1}
              x x x x x
         x x x x x x x x x x
      x x x x x x x x x x x x x
   x x x x x x x x x x x x x x x x
  x x x x x x x x x x x x x x x x x
  x x x x x x x x x x x x x x x x x
 x x x x x x x x x x x x x x x x x x
 x x x x x x x x x x x x x x x x x x
 x x x x x x x x x x x x x x x x x x
 x x x x x x x x x x x x x x x x x x
  x x x x x x x x x x x x x x x x x
  x x x x x x x x x x x x x x x x x
   x x x x x x x x x x x x x x x x
      x x x x x x x x x x x x x
          x x x x x x x x x
              x x x x x
4 * c / l / l // result

Edit: 果然我很习惯改语法…… ~~ 改成 then 了

（注：本文包含数学公式，使用 SVG 图形格式，请不要在 RSS 阅读器里阅读本文）

基本上每个程序员都会对 Quake 那个神一样的常量 0x5f3759df 感到惊奇。在 Quake 里，有一段代码是计算光照时候使用的函数，计算 ，那段代码写的真叫经典：

float Q_rsqrt( float number ){
  long i;
  float x2, y;
  const float threehalfs = 1.5F;

  x2 = number * 0.5F;
  y  = number;
  i  = * ( long * ) &y;  // evil floating point bit level hacking
  i  = 0x5f3759df - ( i >> 1 ); // WTF?
  y  = * ( float * ) &i;
  y  = y * ( threehalfs - ( x2 * y * y ) ); // 1st iteration
  // y  = y * ( threehalfs - ( x2 * y * y ) ); // 2nd iteration, this can be removed

  return y
}

任何学过数值分析的人肯定都知道，最后两行干的事情是牛顿迭代法，用迭代逼近算出准确值。整个过程里，先把单精度浮点 number “硬”转换成整数，进行一个非常诡异的减法后捣腾回实数，然后进行牛顿迭代。那个诡异的步骤显然是算出 的一个近似值，而且从只迭代了一次看，猜测的非常好。因为是计算光照用，千分之一的误差是可以允许的，否则，多迭代几行就是。

这肯定会引来无数人遐想的。不过你看过下面一段内容后就知道其中就里了。

根据 IEEE-754，每一个正的二进制浮点数都可以表示成 。其中， 为其小数位，而 是其指数部分。对于单精度来说， 有 23 个二进制位，而 则有 8 位， 。

我们把它转换成“无符号整数形式” 。对比两者可以得到：

那好，为了计算 ，两边取对数，有：

为了去掉那个该死的对数，考虑到 在[0, 1] 上， ，在这里引入一个常数 σ 使得 。于是：

这样就可以解释那一行里那个著名的 0x5f3759df 实际上就是 。取 σ = 0 代入尝试，可得到 R = 1598029824 = 0x5f400000。这个数值已经比较接近了，然而还不准确，毕竟这里 σ = 0。

那么 σ 设置成多少合适呢？由于希望用牛顿法计算，自然需要让 和 差异尽量小。我使用的是最小二乘法，即计算积分：

积分 的结果是 σ 的二次函数，可算出其最小值时，σ 为 。利用这个 σ 计算出的 R = 0x5f34ff58。Quake 里使用的 σ = 0.0450461875791687011756，比用最小二乘法算出的 σ 小。另一个可以选用的 σ 是 在 [0, 1] 上的最大值的一半，为 ，算出的 R 为 1597488340 = 0x4f37bcb6。

当然了，用最小二乘法去“猜” σ 并不是非常好，最好的 σ 肯定是用大量实验选择的， 这个 σ 值并不是非常好的值，但是作为一次尝试，已经是很不错了。

从 8 行到 17259 行。从一个侧面也证明了把静态语言“编译”成动态语言有多困难。Dart 注定是个笑话。

ps. 今天 Eisa 的总行数只有 4643 行。

第十二：http://www.cnblogs.com/Ninputer/archive/2011/08/02/2120435.html

没想到作者自己坑掉了 0_0
那我也跟着坑掉好了（本来还想看看后端技术地说）

miniSharp 语言是 C# 的一个小子集，然而它仍然具有一门完整编程语言的所有要素，而且仍然是一种面向对象的语言。我们把 miniSharp 的语法分成三类——声明结构、语句和表达式。声明结构就是类、方法、字段的声明。语句就是诸如 if-else、while 这样特定含义的指令。而表达式则是表示一种有运算结果的结构，如二元运算符表达式、函数调用表达式等。C# 中赋值也是一种表达式，但 miniSharp 为了简化后续代码生成，将赋值当成一种语句。

首先来定义声明结构的文法。为了简化语义分析，我们规定程序中第一个类必须是一个静态类，静态类中只能有一个静态方法Main——这是整个miniSharp唯一允许的静态方法。在静态类之后可以定义多个普通类，普通类之间可以继承。下面定义文法的产生式采用了扩展写法，支持类似克林闭包的 * 符号。G → X* 代表 G → ε; G → H; H → X G。

Program     →	MainClass ClassDecl*
MainClass   →	static class ID { public static void Main (string[] ID) 
             	{ Statement+ } } 
ClassDecl   →	class ID { FieldDecl MethodDecl } 
            →	class ID : ID { FieldDecl MethodDecl } 
FieldDecl   →	Type ID;
MethodDecl  →	public Type ID (FormalList) 
             	{ Statement* return Exp ; } 
FormalList  →	Type ID FormalRest*
            →	ε 
FormalRest  →	, Type ID
Type        →	int[] 
            →	bool 
            →	int 
            →	ID
 

语句部分我们将要定义语句块和六种语句。其中if-else语句的else部分是不能省略的。while语句不支持break。剩下四种分别是调用Console.WriteLine的语句、赋值语句、数组元素赋值语句和变量声明语句。

Statement →	{ Statement* } 
          →	if ( Exp ) Statement else Statement
          →	while ( Exp ) Statement
          →	System.Console.WriteLine( Exp ) 
          →	ID = Exp ; 
          →	ID [ Exp ] = Exp ; 
          →	Type ID ; 
 

表达式部分我们将要定义二元、一元、数组长度、数组访问、字面常量、变量、this引用、new运算、方法调用等多种表达式。

Exp	→	Exp op Exp
	→	Exp[ Exp ]
	→	Exp .Length
	→	Exp .ID ( ExpList )
	→	INTEGER_LITERAL
	→	true
	→	false
	→	ID
	→	this
	→	new int [ Exp ]
	→	new ID ()
	→	! Exp
	→	( Exp )
ExpList	→	Exp ExpRest*
	→	ε
ExpRest	→	, Exp
 

其中二元运算表达式的 op 是 +、-、*、/、>、<、==、&& 和 || 之一。为了简单起见我们这里的二元运算表达式文法是有歧义而且没有正确定义优先级的。按照 C# 的语言规范，运算符的优先级关系如下（只提取了 miniSharp 支持的部分）：

有些语法分析器就是使用有歧义的二元运算符文法，在遇到歧义时使用预定义的运算符优先级来解决冲突。现在的语法分析器倾向于直接使用无歧义的文法。下面的文法就是经过精心安排的运算符文法，消除了歧义并使得运算符具有左结合和优先级的区别：

BasicExp    →	括号、new、this、变量、常量、方法调用、属性访问、数组访问
Factor      →	BasicExp
            →	! Factor
Term        →	Factor
            →	Term op Factor   其中 op 是 * /
Comparand   →	Term
            →	Comparand op Term   其中 op 是 + -
Comparison  →	Comparand
            →	Comparison op Comparand    其中 op 是 < > ==
Logical	    →	Comparison
            →	Logical && Comparison
Exp         →	Logical
            →	Exp || Logical
 

这样我们就定义了miniSharp的完整文法。注意，上述文法仍然存在一些左公因式和左递归的现象。我们用的解析器组合子因为独特的广度优先分支判断方式，其支持的文法实际上已经超越了递归下降语法分析器的 LL(k) 文法，称作 LL(∞) 的文法，这种文法非常强大，可描述所有确定性下推自动机 DPDA 接受的语言。但是，它仍然不允许文法存在左递归，而左公因式也会大大降低解析器的效率。所以消除左递归和尽量避免左公因式仍然是真正实现语法分析器时需要着重考虑的任务。

现代语言的语法分析器通常都是将源代码翻译成一棵抽象语法树（Abstract Syntax Tree，AST）。后续的语义分析可以在抽象语法树上继续进行。我们在语法分析篇（六）介绍过“语法分析树”，它是一种在文法推导过程中建立起来的树状数据结构。那么什么是抽象语法树呢？其实就是经过简化和抽象的语法分析树。在完整的语法分析树中每个推导过程的终结符都包含在语法树内，而且每个非终结符都是不同的节点类型。实际上，如果仅仅是要做编译器的话，很多终结符（如关键字、各种标点符号）是无需出现在语法树里的；而前面表达式文法中的 Factor、Term 也实际上没有必要区分为两种不同的类型，可以将其抽象为 BinaryExpression 类型。这样简化、抽象之后的语法树，更加利于后续语义分析和代码生成。使用 0.NET 里的面向对象语言来实现语法树，最常见的做法就是用组合模式，将语法树做成一颗对象树，每种抽象语法对应一个节点类。下图就是 miniSharp 的抽象语法树的所有类。

节选其中一个语法树节点展示一下，比如大家熟悉的IfElse语句的语法树节点类：

public class IfElse : Statement
{
	public Expression Condition { get; private set; }
	public Statement TruePart { get; private set; }
	public Statement FalsePart { get; private set; }
	public SourceSpan IfSpan { get; private set; }
	public SourceSpan ElseSpan { get; private set; }
 
	public IfElse(Expression cond, Statement truePart, Statement falsePart, SourceSpan ifSpan, SourceSpan elseSpan)
	{
		Condition = cond;
		TruePart = truePart;
		FalsePart = falsePart;
		IfSpan = ifSpan;
		ElseSpan = elseSpan;
	}
 
	public override T Accept(IAstVisitor visitor)
	{
		return visitor.VisitIfElse(this);
	}
}
 

它的结构非常简单，里面保存了所有作为子节点成分的字段，例如 IfElse 是由一个 Condition 表达式和 TruePart、FalsePart 两个语句组成。另外我们还多储存了两个 SourceSpan，分别是 if 语句中“if”关键字和“else”关键字出现的源代码位置（多少行，多少列）。保存位置是为了后续语义分析中提供错误信息的位置。比如 if 的条件表达式必须是个 bool 类型的表达式，但语法分析阶段无法做出类型验证，而到了语义分析阶段分析出了语义错误，仍然需要向编译器用户提供错误的位置，这些 SourceSpan 就可以派上用场。

注意节点类最后还实现了一个 Accept 方法，用来支持语法树的 Visitor 模式。我们在语义分析阶段和代码生成阶段，需要一次又一次地遍历抽象语法树。为了简化语法树的访问，我们声明一个 IAstVisitor<T> 接口作为语法树的 Visitor，后续过程需要遍历语法树时，就实现这一接口即可。实际上这个接口有一个默认实现—— AstVisitor 类，允许只重写一部分成员。

有了 Ast，下面我们就开始编写 miniSharp 的语法分析器。在本系列的第五篇中我们已经用 VBF 词法分析库定义了 miniSharp 的词法，生成了一些 Token 对象。那么接下来就只要使用 Linq 语法的解析器组合子，根据本篇开头定义的文法进行组合，并适时使用 select 语句生成语法树节点的对象即可。比如，文法最开始的 Program 和 MainClass 的写法如下：

PProgram.Reference = // MainClass ClassDecl*
	from main in PMainClass
	from classes in PClassDecl.Many()
	select new Program(main, classes);
 
PMainClass.Reference = // static class id { public static void Main(string[] id) { statement }}
	from _static1 in K_STATIC
	from _class in K_CLASS
	from className in ID
	from _1 in LEFT_BR
	from _public in K_PUBLIC
	from _static2 in K_STATIC
	from _void in K_VOID
	from _main in K_MAIN
	from _2 in LEFT_PH
	from _string in K_STRING
	from _3 in LEFT_BK
	from _4 in RIGHT_BK
	from arg in ID
	from _5 in RIGHT_PH
	from _6 in LEFT_BR
	from statements in PStatement.Many1()
	from _7 in RIGHT_BR
	from _8 in RIGHT_BR
	select new MainClass(className, arg, statements);
 

这代码是如此的直白以至于没什么可解释的。唯一要注意的是 PProgram.Reference 这个用法，这里 PProgram 是 ParserReference<T> 类的实例。这个类允许先直接 new 出来，然后再用 .Reference = XXX 的方式为其指定语法规则。这样就允许一个 Parser 组合子先使用，后定义（比如上面例子中的 PMainClass 就先在 PProgram 的语法定义中使用了，然后下面才定义其语法）。因为文法中的非终结符常常出现递归引用，用 ParserReference 这个类可以大大简化我们的工作，不用关心 Parser 的声明先后顺序问题。

我们重点来看一些需要特殊技巧的例子。首先是声明方法形式参数的文法，采用了 FormalList → Type ID FormalRest* 这样的定义方法，这是避免左递归的技巧。但是这样一来，方法的第一个参数就和其他的参数分别定义在两个语法当中。我们希望生成的抽象语法树不区分第一个参数和其余参数，所以可以在生成语法树时采用一点点小技巧来办到：

var paramFormal =
	from paramType in PType
	from paramName in ID
	select new Formal(paramType, paramName);
 
PFormalList.Reference = // Type id FormalRest* |  
	(from first in paramFormal
	 from rest in PFormalRest.Many()
	 select new[] { first }.Concat(rest).ToArray()) |
	Parsers.Succeed(new Formal[0]);
 
PFormalRest.Reference = // , Type id
	paramFormal.PrefixedBy(COMMA.AsParser());
 

另外注意扩展的产生式 “X*” 在VBF解析器组合子库中可以直接使用 X.Many() 的方式实现。VBF 中还定义了数个这种方便的扩展组合子。

最后要注意的是二元运算符的分析器。我们前面写出的无歧义符合优先级的二元运算符文法仍然是左递归的，用于解析器组合子时必须像上面的 FormalList 那样改成右递归的。但是这些运算符都是左结合的，我们不想让生成的抽象语法树也变成右递归的形态。因此，这里我们需要用（传统） Linq 的 Aggregate 扩展方法来处理一下生成的语法树：

var termRest =
	from op in (ASTERISK.AsParser() | SLASH.AsParser())
	from factor in PFactor
	select new { Op = op, Right = factor };
 
PTerm.Reference = // term * factor | factor
	from factor in PFactor
	from rest in termRest.Many()
	select rest.Aggregate(factor, (f, r) => new Binary(r.Op, f, r.Right));
 
var comparandRest =
	from op in (PLUS.AsParser() | MINUS.AsParser())
	from term in PTerm
	select new { Op = op, Right = term };
 
PComparand.Reference = // comparand + term | term
	from term in PTerm
	from rest in comparandRest.Many()
	select rest.Aggregate(term, (t, r) => new Binary(r.Op, t, r.Right));
 
 
var comparisonRest =
	from op in (LESS.AsParser() | GREATER.AsParser() | EQUAL.AsParser())
	from comparand in PComparand
	select new { Op = op, Right = comparand };
 
PComparison.Reference = // comparison < comparand | comparand
	from comparand in PComparand
	from rest in comparisonRest.Many()
	select rest.Aggregate(comparand, (c, r) => new Binary(r.Op, c, r.Right));
 

除此之外，剩下的语法翻译成组合子基本上都是水到渠成的工作了。完整的代码全部都在 MiniSharpParser.cs 中，大家可以自行下载阅读。经过小小的努力，我们终于能将 miniSharp 的源代码转换为抽象语法树了，接下来我们就要进入下一个编译器重要的阶段——语义分析。敬请期待下一篇！

首先来看上一个版本的四个基本组合子：空产生式的 Succeed 组合子， token 产生式的 AsParser 组合子，连接运算产生式的 SelectMany 组合子和并运算产生式的 Union 组合子。首先 Succeed 是不会解析失败的，所以它没有必要进行错误恢复。现在来看 AsParser 组合子，它的逻辑是读取下一个词素，如果词素的单词类型和组合子的参数匹配则解析成功，否则解析失败。代码如下：

public static ParserFunc<Lexeme> AsParser(this Token token)
{
    return scanner =>
    {
        var lexeme = scanner.Read();
        if (lexeme.TokenIndex == token.Index)
        {
            return new Result<Lexeme>(lexeme, scanner);
        }
        else
        {
            return null;
        }
    };
}

如果要对失败的情形进行错误恢复，有两种可行的选择： 1 、假装要解析的 Token 存在，继续解析（这种做法相当于在原位置插入了一个单词）； 2 、跳过不匹配的单词，重新进行解析（这种做法相当于删除了一个单词）。如果漏写一个分号或者括号，插入型错误恢复就能有效地恢复错误，如果是多写了一个关键字或标识符造成的错误，删除型错误恢复就能有效地恢复。但问题是，我们怎么能在组合子的代码中判断出哪种错误恢复更有效呢？最优策略是让两种错误恢复的状态都继续解析到末尾，然后看哪种恢复状态整体语法错误最少。但是，只要有一个字符解析失败，就要分支成两个完整解析，那么错误一旦多起来，这个分支的庞大程度将使得错误恢复无法进行。更何况，错误并不仅仅出现在真正的语法错误上，我们还要用错误来判断“并”运算组合子的分支问题。请看上一版本 Union 组合子的代码：

public static ParserFunc<T> Union<T>(this ParserFunc<T> parser1, ParserFunc<T> parser2)
{
    return scanner =>
    {
        var scanner1 = scanner;
        var scanner2 = scanner.Fork();

        var result1 = parser1(scanner1);
        if (result1 != null)
        {

            return result1;
        }

        var result2 = parser2(scanner2);

        return result2;
    };
}

在 Union 中，我们先试验第一个 parser1 能否解析成功，如果失败才解析 parser2 。如果解析器有自动错误恢复的功能，那么我们就无法用这种方式判断了，因为两条分支遇到错误之后都会继续进行下去。我们可以让两条分支都解析到底，然后挑错误较少的分支作为正式解析结果。但同上所述，这种做法的分支多得难以置信，效率上决定我们不能采用。

为了避免效率问题，我们需要一种“广度优先”的处理方案。在遇到错误时产生的“插入”和“删除”两条分支，要同时进行，但要一步一步地进行。这里所谓的一“步”，就是指 AsParser 组合子读取一个词素。我们看到四种基本组合子中，只有 AsParser 组合子会用 scanner 来真正读取词素，其他组合子最终也是要调用到 AsParser 组合子来进行解析的。我们让两个可能的分支都向前解析一步，然后看是否其中一条分支的结果比另外一条更好。所谓更好，就是一条分支没有进一步遇到错误，而另外一条分支遇到了错误。如果两条分支都没有遇到错误，或者都遇到了错误，我们就再向前推进一步，直到某一步比另外一步更好为止。 Union 组合子也可以采用同样的策略处理。这是一种贪心算法的策略，我们所得到的结果未必是语法错误最少的解析结果，但它的效率是可以接受的。

那么怎么进行“广度优先”推进呢？我们上次引入的组合子，当前的组合子无法知道下一个要运行的组合子是什么，更无法控制下一个组合子只向前解析一步。为了达到目的，我们要引入一种新的组合子函数原型，称作CPS（ Continuation Pass-in Style ）风格的组合子。不知道大家有多少人听说过 CPS ，这在函数式编程界是一种广为应用的模式，在.NET 世界里其实也有采用。.NET 4.0 引入的 Task Parallel Library 库中的 Task 类，就是一个典型的 CPS 设计范例。我举一个简单的例子来介绍一下 CPS 。如果有两个函数 A 和 B ，需要按顺序调用，用传统方式编程很简单，就是直接调用：

void A()
{
    Console.WriteLine("A");
}

void B()
{
    Console.WriteLine("B");
}

void Run()
{
    A();
    B();
}

而如果采用 CPS ，则是把 B 传递给 A ，这时我们称 B 是 A 的 continuation ，或者 future 。

void A(Action future)
{
    Console.WriteLine("A");
    future();
}

void B()
{
    Console.WriteLine("B");
}

void Run()
{
    A(B);
}

乍一看这也不能实现什么特别的事情，但其实是很有用的。 A 获得了自己的 future 之后可以自行决定如何运行它。比如可以异步地运行。这样我们就在 Run()方法中，用一种容易理解的方式，构建出了一条异步调用序列。.NET 4.0 的 Task Parallel Library 正是这样的风格，每个 Task 类通过 ContinueWith 方法接受自己的 future 。而我们的函数式解析其组合子，也可以用这种方式，让每个 Parser 函数接受一个 future ，并自行决定如何调用 future 。这里最关键的思想是实现延迟调用future ，从而实现“广度优先”的单步解析效果。首先来看看新的 Parser 类原型（警告，这一篇里采用的函数式技巧比上一篇还要难懂得多，如果看了之后发生头晕，嗜睡等症状，请休息之后重新看……）：

public delegate Result<T> ParserFunc<T>(ForkableScanner scanner, ParserContext context);
public delegate ParserFunc<TFuture> Future<T, TFuture>(T value);

public abstract class Parser<T>
{
    public abstract ParserFunc<TFuture> BuildParser<TFuture>(Future<T, TFuture> future);
}

ParserFunc 方法和上一篇非常类似，但是多了一个 ParserContext 方法。我们会用这个对象来保存一些错误报告的信息。再来是 Future 函数的定义， Future 返回的类型是一个 ParserFunc 委托对象； Future 的参数 T ，则是用来让每一个组合子生成的 Parser ，将自己的解析结果 T 传给它自己的 Future 用的。注意这次多了一个 Parser<T>抽象类，它代替 ParserFunc 成为组合子的生成对象。它之所以不能声明成一个委托，是因为它的 BuildParser 方法要接受一个额外的泛型类型参数 TFuture 。接下来每一个解析器组合子都需要继承自 Parser<T>，并实现它的 BuildParser 方法。下面我们就来看一看新的 CPS 型解析器组合子怎么定义。

首先还是 G → ε的组合子，它永远都能解析成功，所以，它的逻辑是生成一个 ParserFunc ，将预设的解析结果传递给自己的 Future:

public class SucceedParser<T> : Parser<T>
{
    public T Value { get; private set; }

    public SucceedParser(T value)
    {
        Value = value;
    }
    public override ParserFunc<TFuture> BuildParser<TFuture>(Future<T, TFuture> future)
    {
        return (scanner, context) => future(Value)(scanner, context);
    }
}

这是第一次实践 CPS 风格，大家一定要注意观察它与上一次传统风格解析器组合子的不同。最关键的一点，就是返回的 ParserFunc ，必须要调用 BuildParser 传进来的 future 函数，传递自己的解析结果。

接下来就是重头戏 G → t ，我们要在这个单词解析器组合子中加入期待已久的错误报告和错误恢复功能，请看代码：

public class TokenParser : Parser<Lexeme>
{
    public Token ExpectedToken { get; private set; }
    public string MissingCorrection { get; private set; }

    public TokenParser(Token expected)
    {
        ExpectedToken = expected;
        MissingCorrection = expected.ToString();
    }


    public override ParserFunc<TFuture> BuildParser<TFuture>(Future<Lexeme, TFuture> future)
    {
        ParserFunc<TFuture> scan = null;
        scan = (scanner, context) =>
        {
            var s1 = scanner.Fork();

            var l = scanner.Read();

            int tokenIndex;
            tokenIndex = l.TokenIndex;

            if (tokenIndex == ExpectedToken.Index)
            {
                var r = context.StepResult(0, () => future(l)(scanner, context));
                return r;
            }
            else
            {
                Lexeme correctionLexeme = l.GetErrorCorrectionLexeme(ExpectedToken.Index, MissingCorrection);
                ErrorCorrection insertCorrection = new InsertedErrorCorrection(ExpectedToken.ToString(), correctionLexeme.Span);

                if (l.IsEndOfStream)
                {
                    scanner.Join(s1);
                    return context.StepResult(1, () => future(correctionLexeme)(scanner, context), insertCorrection); //插入
                }
                else
                {
                    ErrorCorrection deleteCorrection = new DeletedErrorCorrection(l);
                    return context.ChooseBest(context.StepResult(1, () => future(correctionLexeme)(s1, context), insertCorrection), //插入
                        context.StepResult(1, () => scan(scanner, context), deleteCorrection)); //删除
                }
            }
        };

        return scan;
    }
}

大致描述下来就是生成这样一个 ParserFunc ：首先通过 Scanner 读取下一个词素，并判断它是否是期待的单词。如果是，则调用 context.StepResult(0, …)方法（稍后解释）；如果不是，则判断是否遇到的输入流的末尾，如果是末尾，则只尝试“插入”修复方案（因为无法删除“流末尾”单词），如果不是末尾则使用 context.ChooseBest 方法，尝试插入和删除两种修复方案。 context.StepResult 方法就是产生延迟执行 future 的关键。它的第一个参数表示该结果的“代价”， 0 表示这是一个成功解析的结果； 1 表示是经过错误恢复的结果。第二个参数则是一个延迟执行的委托，这个委托只会在我们需要将解析器“推进一步”的时候才会执行，我们将 future 函数的调用放在这里并做成延迟执行的方式，就是要等待广度优先一步一步地向前解析时才执行下一步的操作。那么这个 context.ChooseBest 函数到底是如何实现的呢？请看代码：

private Result<T> ChooseBest<T>(Result<T> result1, Result<T> result2, int correctionDepth)
{
    if (result1.Type == ResultType.Stop)
    {
        return result1;
    }
    if (result2.Type == ResultType.Stop)
    {
        return result2;
    }

    var step1 = (StepResult<T>)result1;
    var step2 = (StepResult<T>)result2;

    if (step1.Cost < step2.Cost)
    {
        return step1;
    }
    else if (step1.Cost > step2.Cost)
    {
        return step2;
    }
    else
    {
        return new StepResult<T>(Math.Max(step1.Cost, step2.Cost), 
            () => ChooseBest(step1.NextResult, step2.NextResult, correctionDepth + 1), null);
    }
}

ChooseBest 方法要比较两个 Result 的代价，并选取代价较小的分支。如果代价一样，则通过延迟计算的方法将比较推至下一轮。我们到处采用延迟计算的手段，以至于整个单词流都输入之后，解析可能仍然没有结束！所以 Result 类有一个集中取得每一步结果的功能，在单词流输入完毕后还要继续驱动这些延迟计算，直到拿到最终的解析结果。

接下来是表示连接运算 G → X Y 的 SelectMany 组合子。具体方法是将传入的 future 作为 Y 的 future ，再将 Y 的 Parser 作为 X 的 future ，以此将两者连接起来：

public class ConcatenationParser<T1, T2, TR> : Parser<TR>
{
    public Parser<T1> ParserLeft { get; private set; }
    public Func<T1, Parser<T2>> ParserRightSelector { get; private set; }
    public Func<T1, T2, TR> Selector { get; private set; }

    public ConcatenationParser(Parser<T1> parserLeft, Func<T1, Parser<T2>> parserRightSelector, Func<T1, T2, TR> selector)
    {
        CodeContract.RequiresArgumentNotNull(parserLeft, "parserLeft");
        CodeContract.RequiresArgumentNotNull(parserRightSelector, "parserRightSelector");
        CodeContract.RequiresArgumentNotNull(selector, "selector");

        ParserLeft = parserLeft;
        ParserRightSelector = parserRightSelector;
        Selector = selector;
    }

    public override ParserFunc<TFuture> BuildParser<TFuture>(Future<TR, TFuture> future)
    {
        return (scanner, context) => 
            ParserLeft.BuildParser(
                left => ParserRightSelector(left).BuildParser(
                    right => future(Selector(left, right))))(scanner, context);
    }
}

最后的并运算，则是广度优先同时实验两个传入的 Parser ，即直接用 ChooseBest 方法选取继续执行的 Parser ：

public class AlternationParser<T> : Parser<T>
{
    public Parser<T> Parser1 { get; private set; }
    public Parser<T> Parser2 { get; private set; }

    public AlternationParser(Parser<T> parser1, Parser<T> parser2)
    {
        CodeContract.RequiresArgumentNotNull(parser1, "parser1");
        CodeContract.RequiresArgumentNotNull(parser2, "parser2");

        Parser1 = parser1;
        Parser2 = parser2;
    }

    public override ParserFunc<TFuture> BuildParser<TFuture>(Future<T, TFuture> future)
    {
        return (scanner, context) =>
        {
            var s1 = scanner;
            var s2 = scanner.Fork();

            return context.ChooseBest(Parser1.BuildParser(future)(s1, context), Parser2.BuildParser(future)(s2, context));
        };
    }
}

如果大家还不能很清晰地理解上述 CPS 风格解析器组合子的原理，也不要担心。我也是花了整整两个星期时间反复看论文才理清所有细节的。而且我贴的也是简化的代码，并不完整。大家可以下载 VBF 库的源代码来仔细研究。当然，如果对 Haskell 不恐惧的话，看原始的论文也不错。从这里下载论文（点右上方 Download 下面的 PDF 图标）：http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.30.7601

最后，我们像上一篇传统解析器组合子那样，为每种组合子声明一个便于使用的静态函数或者扩展方法。注意，在上述四种基本组合子外， CPS 组合子如要正常工作，需要一个特殊的组合子—— EndOfStreamParser ，它类似于 TokenParser 但错误恢复的时候从不尝试插入。这里略过它的实现，直接来看辅助函数的定义：

public static class Parsers
{
    public static Parser<Lexeme> AsParser(this Token token)
    {
        CodeContract.RequiresArgumentNotNull(token, "token");

        return new TokenParser(token);
    }

    public static Parser<Lexeme> Eos()
    {
        return new EndOfStreamParser();
    }

    public static Parser<T> Succeed<T>(T value)
    {
        return new SucceedParser<T>(value);
    }

    public static Parser<TResult> SelectMany<T1, T2, TResult>(this Parser<T1> parser, Func<T1, Parser<T2>> parserSelector, 
        Func<T1, T2, TResult> resultSelector ）
    {
        CodeContract.RequiresArgumentNotNull(parser, "parser");
        CodeContract.RequiresArgumentNotNull(parserSelector, "parserSelector");
        CodeContract.RequiresArgumentNotNull(resultSelector, "resultSelector");

        return new ConcatenationParser<T1, T2, TResult>(parser, parserSelector, resultSelector);
    }

    public static Parser<T> Union<T>(this Parser<T> parser1, Parser<T> parser2)
    {
        CodeContract.RequiresArgumentNotNull(parser1, "parser1");
        CodeContract.RequiresArgumentNotNull(parser2, "parser2");

        return new AlternationParser<T>(parser1, parser2);
    }
}

这样，我们就能和上一篇一样用 Linq 的语法来组合 Parser 了。最后我们还需要一个驱动延迟计算的类：

public class ParserRunner<T>
{
    public ParserContext Context { get; private set; }
    private ParserFunc<T> m_runner;

    public ParserRunner(Parser<T> parser, ParserContext context)
    {
        CodeContract.RequiresArgumentNotNull(parser, "parser");
        CodeContract.RequiresArgumentNotNull(context, "context");

        m_runner = parser.BuildParser(FinalFuture);
        Debug.Assert(m_runner != null);
        Context = context;
    }

    public T Run(ForkableScanner scanner)
    {
        var result = m_runner(scanner, Context);
        return result.GetResult(Context);
    }

    private ParserFunc<T> FinalFuture(T value)
    {
        return (scanner, context) => context.StopResult(value);
    }
}

这个类里我们定义了整个解析器最终的一个 future ——它产生令所有分支判断停止的 StopResult 。这里最关键的是利用 result.GetResult 虚方法推进广度优先的分支选取，并且收集这条路线上所有的语法错误。我们所有的语法错误就只有两种：“丢失某单词”（采用了插入方式错误恢复）和“发现了未预期的某单词”（采用了删除方式错误恢复）。

下面的例子演示了真正的 VBF.Compilers.Parsers.Combinators.dll 库的用法。真正的 VBF 库除了定义基本组合子之外还定义了许许多多的重载和扩展函数，基本实现了 EBNF 的所有功能（而且还可以很容易地继续无限扩展）。用 VBF 库时 Linq 语句可以直接在 Token 上使用，而无需到处使用 AsParser 扩展方法。此外还有大量的代码，限于逻辑无法全部在博客中展现，大家如想了解最好的方法还是直接下载我的代码观看和试用。

class Node
{
    public Node LeftChild { get; private set; }
    public Node RightChild { get; private set; }
    public char Label { get; private set; }

    public Node(char label, Node left, Node right)
    {
        Label = label;
        LeftChild = left;
        RightChild = right;
    }
}

class Program
{
    static void Main(string[] args)
    {
        Lexicon binaryTreeSyntax = new Lexicon();
        LexerState lex = binaryTreeSyntax.DefaultLexer;

        //定义词法
        Token LEFTPH = lex.DefineToken(RE.Symbol('('));
        Token RIGHTPH = lex.DefineToken(RE.Symbol(')'));
        Token COMMA = lex.DefineToken(RE.Symbol(','));
        Token LETTER = lex.DefineToken(RE.Range('a', 'z') | RE.Range('A', 'Z'));

        espan style="color: green">//定义语法
        ParserReference<Node> NodeParser = new ParserReference<Node>();
        NodeParser.Reference =
            (from a in LETTER
             from _1 in LEFTPH
             from left in NodeParser
             from _2 in COMMA
             from right in NodeParser
             from _3 in RIGHTPH
             select new Node(a.Value[0], left, right))
            | Parsers.Succeed<Node>(null);

        var builder = new ForkableScannerBuilder(binaryTreeSyntax.CreateScannerInfo());

        string source = "A(B(,),C(,))";
        SourceReader sr = new SourceReader(
            new StringReader(source));


        ForkableScanner scanner = builder.Create(sr);
        CompilationErrorManager errorManager = new CompilationErrorManager();

        ParserContext context = new ParserContext(errorManager, 0, 1);
        context.DefineDefaultCompilationErrorInfo(0);

        var runner = new ParserRunner<Node>(NodeParser.SuffixedBy(Parsers.Eos()), context);
        var result = runner.Run(scanner);

        foreach (var error in errorManager.Errors.OrderBy(e => e.ErrorPosition.StartLocation.CharIndex))
        {
            Console.WriteLine(error.ToString());
        }
    }
}

注意 from 语句已经可以直接使用 Token 类型， Union 操作也可以用“|”运算符代替。由于广度优先分支判断的缘故，整个文法在用于解析之前，必须在后面连接一个 EndOfStream ，代表解析到文件末尾才算结束。最后的代码还演示了如何将解析错误打印出来。大家可以将输入字符串故意改错，看看是否能够检测出来。还可以试试错误太多太离谱时的性能下降现象。

在下一篇，我们将正式用这套解析器组合子实现 miniSharp 语言的语法分析器，并且还会接触到 VBF 库扩展组合子的各种用法。敬请期待！

希望大家继续关注我的 VBF 项目：https://github.com/Ninputer/VBF 和我的微博：http://weibo.com/ninputer 多谢大家支持！

翻译： Belleve Invis

此翻译非直译，可能有部分内容省略，为交流用。如有错漏请回复。

序

十六年来， JavaScript 已经完全占领浏览器。它，见证了网页应用（Web Application）的崛起。尽管其他的脚本语言也能担此重任，然而，命运选择了 JavaScript。尽管微软在数年前就在浏览器里加入了 Basic ，但， JavaScript 因为能在所有浏览器中运行，所以它赢了。因能在所有浏览器中运行，自身的质量又并不差，那些浏览器制造商就没有义务给他们的产品增加新语言。

那些华丽的特性——比如闭包——让她成为我们这些情人眼里的西施。编程圈子里经常有这样的忏悔——“是，我知道，这玩意不怎么样，但是给她个机会，好吗？你会爱上她的。”给这语言推销绝非难事。 JavaScript 被说成一个太早拿出来的实验品，而我们一直戴着有色眼镜。

2007 年， Steve Yegge 说 JavaScript 会“引爆程序圈”，现在看来，是真的。从那时到现在，基于 JavaScript 的网页应用已经变得更复杂、更大型以及更好用。借其力量， Web 仍然保持繁荣，丝毫不让移动 App。

最近， JavaScript 在服务器端成功发力。 Node.js 平台，利用其非阻塞 I/O，有望解决无数程序员多年的积怨。作为 Node.js 的选择， JavaScript 可能会在服务器端完成无数前人没有完成的任务。

总而言之， JavaScript 早已横扫全球。但是，如果浏览器今天从地球上消失，又有多少 JavaScript 代码会在第二天写出来？或许她会一夜之间被打入冷宫。幸而，浏览器不会消失，而且还会存活很多年。

随着开发规模的膨胀，那些缺陷逐渐显现，日复一日戳痛开发人员的心。你会觉得奇怪，为什么我写 JavaScript 那么多年我还不是 JavaScript 教教徒，我写的绝大多数 JavaScript 文章都在说我怎么克服重重障碍与之和谐相处的。我很喜欢 JavaScript 编程，但也很多次感觉犹如陷入泥潭。

一个最明显的缺陷——能直接看到的——就是语法。这问题不解决，它迟早要倒台。

解析器组合子的基本思想是“组合”，首先我们要定义一些最基本的产生式作为基础组合子，然后通过组合的方式拼装出最终的解析器来。回想一下正则表达式的定义，它有两个基本表达式要素——空表达式和字符表达式，以及三个基本运算——并、连接和克林闭包。用基本运算连接基本表达式，就能组成任何正则表达式。解析器组合子也需要定义两个基本的产生式和两个基本运算。

首先是产生空字符的产生式：

G → ε;

这个产生式不产生任何单词，换句话说在解析的时候，不解析任何单词就能成功解析出一个 G。因此这个产生式的解析器永远都能解析成功。

接下来是产生一个单词 t 的产生式：

G → t;

产生式产生一个特定单词 t，表示在解析的时候，如果遇到单词 t，则成功解析出一个 G，而遇到其他单词则会解析失败。 再来定义两个基本运算。首先是连接运算：

G → X Y;

产生式先产生 X 再产生 Y，表示在解析的时候先成功解析 X，再成功解析 Y，就能成功解析出一个 G。

接下来是并运算：

G → X;
G → Y;

这表示，G 既可以产生 X 也可以产生 Y。在解析时无论成功解析 X 还是 Y，都能成功解析出一个 G。以上四种基本产生式嵌套使用，就能表示任何上下文无关文法。

下面定义解析器函数的原型委托：

public delegate IResult<T> ParserFunc<out T>(ForkableScanner scanner);

public interface IResult<out T>
{
    T Value { get; }
    ForkableScanner ReturnedScanner { get; }
}

public class Result<T> : IResult<T>
{
    public T Value { get; private set; }
    public ForkableScanner ReturnedScanner { get; private set; }

    public Result(T value, ForkableScanner returnedScanner)
    {
        Value = value;
        ReturnedScanner = returnedScanner;
    }
}

这并不是 VBF.Compilers.Parsers.Combinators 库最后采用的 Parser 函数原型，但它非常适合第一次接触解析器组合子的同学们理解。先看第一行委托的结构，它接受一个 ForkableScanner 作为参数，然后返回一个 IResult类型。首先什么是 ForkableScanner 呢？我们在词法分析篇定义的 Scanner 类只能不断地向前 Read，而在函数式编程风格中，我们需要一个无副作用的 Scanner。简而言之，任何一个个 ForkableScanner 可以随时“Fork”成两个 ForkableScanner，而这两个 Scanner 任何一个向前扫描，都不会影响另外一个，而且他们各自扫描都回得到同样的单词流。这都是为了处理上述“并”运算的解析器，并运算需要两个分支能够互不影响地单独进行。接下来是返回类型 IResult，定义成接口是为了能够加上.NET 4 泛型协变的“out”关键字。实际类型 Result包含一个解析结果 T 和成功解析之后返回的 Scanner，代表余下的输入流。如果返回的整个 Result 对象为 null，则表示解析失败。后面所有解析器组合子最终都是为了生成这样一个委托的对象，一旦生成了这个对象，就可以马上拿来解析了。

有了解析器函数原型，下面就开始一样一样地定义基础组合子。所谓组合子其实都是一些静态方法（本例中这些静态方法都定义在 Parsers 静态类中）、返回类型就是上面的解析器委托。由于返回类型也是委托，所以这些组合子实际上都是一些高阶函数（返回函数的函数）。在我们的代码中常常是一个 lambda 表达式。较少使用 lambda 表达是的同学第一次看下面的代码可能会略微感到头晕，只需要稍微休息一下再重新看即可……

首先是空产生式 G → ε，它的组合子是：

public static ParserFunc<T> Succeed<T>(T result)
{
    return scanner => new Result<T>(result, scanner);
}

这个组合子接受一个参数，表示其解析结果。正如前面所介绍，由 Succeed 组合子生成的解析器，永远都会成功解析，而且会将设定的结果返回。

第二种是接受一个单词的的产生式 G → t，我们将它的组合子定义成一个扩展方法：

public static ParserFunc<Lexeme> AsParser(this Token token)
{
    return scanner =>
    {
        var lexeme = scanner.Read();
        if (lexeme.TokenIndex == token.Index)
        {
            return new Result<Lexeme>(lexeme, scanner);
        }
        else
        {
            return null;
        }
    };
}

注意这个组合子生成的解析器是 Lexeme（词素）类型的，词素对象是我们在词法分析阶段定义的，里面包含了词素的类型和具体字符串。这个组合子接受一个 Token 作为参数，而返回的解析器从输入的 Scanner 中读取下一个词素，如果该词素的单词类型与传入的 Token 相匹配，就报告解析成功，否则解析失败。

第三种是两个文法的连接 G → X Y。我们需要定义一个组合子，接受两个已经存在的 ParserFunc 函数，返回一个新的 ParserFunc，先后调用两个传入的 ParserFunc：

public static ParserFunc<Tuple<T1, T2>> Concat<T1, T2>
        (this ParserFunc<T1> parser1, ParserFunc<T2> parser2)
{

    return scanner =>
    {
        var result1 = parser1(scanner);

        if (result1 == null) return null;

        var result2 = parser2(result1.ReturnedScanner);

        if (result2 == null) return null;

        return new Result<Tuple<T1, T2>>(
            Tuple.Create(result1.Value, result2.Value), result2.ReturnedScanner);
    };
}

注意我们返回的 ParserFunc 结果类型是 Tuple<T1, T2> ，因为结果中需要同时包含 T1 和 T2。

用这种方式定义的连接运算组合子，在实践中非常难用。因为我们的文法常常要包含不止两个符号连接的情形。假如我们的产生式是 G → X Y Z，那么必须写成 X.Concat(Y.Concat(Z)) ，而它的返回类型是 Tuple<T1, Tuple<T2, T3>> ，如果要取得结果中的 Z，只能写 r.Item2.Item2。实际上 miniSharp 这样的语言，文法中出现 7-8 个符号连接也不是什么稀奇的事情，而如果都用这个组合子的话， Tuple 嵌套会复杂到把人的眼睛都搞晕掉。所以这时我们想到了——Linq。 Linq 的“组合子”中，有一种叫 SelectMany，他给我们带来了这种语法糖：

List<int> la = new List<int>() { 1, 2, 3 };
List<string> lb = new List<string>() { "a", "b", "c" };

var r = from a in la
        from b in lb
        select a + b;

它实际可以翻译成：

var r = la.SelectMany(a => lb.SelectMany(b => a + b));

也就是说，连续 from 语句，其实是 SelectMany 扩展方法的嵌套调用。这种调用方法有把 lambda 嵌套“打平”的功能，非常类似于单子风格中的 Bind 运算。实际上 C# 和 VB 允许在任何自定义类型上扩展 SelectMany 方法，然后就允许用 Linq 语法的 from 去调用。有些人非常鄙视语法糖，但这个语法糖却是无法替代的，这是 C# 版解析器组合子关键中的关键！由此就可以将连接运算定义成一个 SelectMany 组合子：

public static ParserFunc<TResult> SelectMany<T1, T2, TResult>(this ParserFunc<T1> parser,
    Func<T1, ParserFunc<T2>> parserSelector, Func<T1, T2, TResult> resultSelector)
{

    return scanner =>
    {
        var result1 = parser(scanner);

        if (result1 == null) return null;

        var parser2 = parserSelector(result1.Value);

        var result2 = parser2(result1.ReturnedScanner);

        if (result2 == null) return null;

        return new Result<TResult>(
            resultSelector(result1.Value, result2.Value), result2.ReturnedScanner);
    };
}

这个神奇的 SelectMany 组合子不但消除了嵌套 Tuple 带来的混乱，还允许我们用一个自定义的 select 语句生成连接运算的结果，这在生成语法树的时候尤为方便。我们一会再看例子，先继续看最后一种基本组合子。

最后一种基本组合子是并运算。并运算要求产生式产生两种可能的分支。对应到解析器组合子上，连接运算也要接受两个现成的解析器作为参数，但是选择哪一个呢？这里我们没有办法做分支预测，所以只好采取尝试的办法。有一种尝试的方法就是先试用第一个解析器，如果失败了，再试用第二个，这是一种类似深度优先搜索的办法：

public static ParserFunc<T> Union<T>(this ParserFunc<T> parser1, ParserFunc<T> parser2)
{
    return scanner =>
    {
        var scanner1 = scanner;
        var scanner2 = scanner.Fork();

        var result1 = parser1(scanner1);
        if (result1 != null)
        {

            return result1;
        }

        var result2 = parser2(scanner2);

        return result2;
    };
}

仅仅使用以上四个组合子函数，就可以来写 Parser 了！是否还半信半疑呢？我们就来写上一次写过的二叉树字符串表示的语法分析器。忘记的同学建议打开上一篇看看。我们把文法再抄一遍：

N → a ( N, N )
N → ε

这里面涉及的单词包括字母、左右括号和逗号，我们都用词法分析篇的方法将他们定义出来。然后再用解析器组合子组合出上述文法的解析器。完整的代码如下：

Lexicon binaryTreeSyntax = new Lexicon();
LexerState lex = binaryTreeSyntax.DefaultLexer;

//定义词法
Token LEFTPH = lex.DefineToken(RE.Symbol('('));
Token RIGHTPH = lex.DefineToken(RE.Symbol(')'));
Token COMMA = lex.DefineToken(RE.Symbol(','));
Token LETTER = lex.DefineToken(RE.Range('a','z') | RE.Range('A','Z'));

//定义语法
ParserFunc<Node> NodeParser = null;
NodeParser = 
    (from a in LETTER.AsParser()
     from _1 in LEFTPH.AsParser()
     from left in NodeParser
     from _2 in COMMA.AsParser()
     from right in NodeParser
     from _3 in RIGHTPH.AsParser()
     select new Node(a.Value[0], left, right))
    .Union(Parsers.Succeed<Node>(null));


//运行部分
ForkableScannerBuilder builder = 
    new ForkableScannerBuilder(binaryTreeSyntax.CreateScannerInfo());

string source = "A(B(,),C(,))";
SourceReader sr = new SourceReader(
    new StringReader(source));

ForkableScanner scanner = builder.Create(sr);

var tree = NodeParser(scanner);

重点来看“定义语法”部分，我们来看看产生式都是如何转变为组合子调用的。首先，N → ε 转化为了一句 Parsers.Succeed 调用，代表总能解析成功，而且不消耗输入单词的解析器。然后是 N → a ( N, N )，连续的连接转化为一连串 Linq 的 from 子句。而其中出现了终结符的地方，则通过 AsParser 扩展方法将 Token 转化为 Parser。最后再用一个 Union 组合子将两个 N 产生式组合到一起，中间我们还看到了用 select 子句方便地构造想要的解析结果能力。再一次，赞叹 SelectMany 的神奇力量！初看起来， Linq 用来写文法感觉怪怪的，但是习惯了之后，可以非常快速地将各种产生式以 Linq 语句的方式表达出来。

解析器组合子最大的优点就是无论实现还是使用都非常简洁，高度体现了函数式编程的优势。但它最大的缺点是难以调试。倘若大家用解析器组合子组合出来的解析器有错误，无法获得想要的解析结果，那可就麻烦了。大家可以试试用 Visual Studio 的调试器跟踪一下解析器组合子，会发现它的跳转非常频繁，而且根本看不出当前在干什么（因为运行时已经生成了 Lambda 函数，无法获得组合子传入的参数），也无法看出下一步会运行什么。所以，采用解析器组合子唯一确保正确的做法，就是编写足够的测试用例。

还有一个重要的问题要解决——语法错误。大家可以试一试输入一个不符合语法的字符串，比如去掉一个括号，看看会是什么结果？答案是直接返回 null——和一开始的设定一样。无法知道错误出在了哪里。作为编程语言的解析器，不仅应该能报告错误出现的位置，而且还应该能自动进行某种错误恢复，这样就可以继续完成解析，从而获得所有的语法错误，而不仅仅是头一个。这个功能非常重要，但我们今天设计的解析器组合子结构却非常不擅长进行错误报告和恢复。比如说 Union 组合子，干脆就是通过解析错误来判断要不要采用这个分支，如果每个分支都错了，它又如何决定报告哪条分支的错误呢？可以设定一些规则，但是我们想要更好、更智能的错误报告和恢复功能。这就留到下一篇，正式介绍 VBF 库中采用的 CPS 风格解析器组合子了。敬请期待！

希望大家继续关注我的 VBF 项目： http://github.com/Ninputer/VBF 和我的微博： http://weibo.com/ninputer 多谢大家支持！

使用递归下降法编写语法分析器无需任何类库，编写简单的分析器时甚至连前面学习的词法分析库都无需使用。我们来看一个例子：现在有一种表示二叉树的字符串表达式，它的文法是：

N → a ( N, N )
N → ε

其中终结符a表示任意一个英文字母，ε表示空。这个文法的含义是，二叉树的节点要么是空，要么是一个字母开头，并带有一对括号，括号中逗号左边是这个节点的左儿子，逗号右边是这个节点的右儿子。例如字符串 A(B(,C(,)),D(,))就表示这样一棵二叉树：

注意，文法规定节点即使没有儿子（儿子是空），括号和逗号也是不可省略的，所以只有一个节点的话也要写成A(,)。现在我们要写一个解析器，输入这种字符串，然后在内存中建立起这棵二叉树。其中内存中的二叉树是用下面这样的类来表示的：

classNode
{
    public Node LeftChild { get; private set; }
    public Node RightChild { get; private set; }
    public char Label { get; private set; }

    public Node(char label, Node left, Node right)
    {
        Label = label;
        LeftChild = left;
        RightChild = right;
    }
}

这是一道微软面试题，曾经难倒了不少参加面试的候选人。不知在座各位是否对写出这段程序有信心呢？不少参选者想到了要用栈，或者用递归，去寻找逗号的位置将字符串拆解开来等等方法。但是若是使用递归下降法，这个程序写起来非常容易。我们来看看编写递归下降语法分析器的一般步骤：

1. 使用一个索引来记录当前扫描的位置。通常将它做成一个整数字段。
2. 为每个非终结符编写一个方法。
3. 如果一个非终结符有超过一个的产生式，则在这个方法中对采用哪个产生式进行分支预测。
4. 处理单一产生式时，遇到正确终结符则将第一步创建的扫描索引位置向前移动；如遇到非终结符则调用第二步中创建的相应方法。
5. 如果需要产生解析的结果（比如本例中的二叉树），在方法返回之前将它构造出来。

我们马上来试验一下。首先建立一个类，然后存放一个索引变量来保存当前扫描位置。然后要为每一个非终结符创建一个方法，我们的文法中只有一个非终结符N，所以只需创建一个方法：

class BinaryTreeParser
{
    private string m_inputString;
    private int m_index;

    //初始化输入字符串和索引的构造函数，略

    Node ParseNode()
    {
    }
}

回到刚才的产生式，我们看到非终结符N有两个产生式，所以在ParseNode方法的一开始我们必须做出分支预测。分支预测的方法是超前查看（look ahead）。就是说我们先“偷窥”当前位置前方的字符，然后判断应该用哪个产生式继续分析。非终结符N的两个产生式其中一个会产生a(N, N)这个的结构，而另一个则直接产生空字符串。那现在知道，起码有一种可能就是会遇到一个字母，这时候应该采用N → a(N, N)这个产生式继续分析。那么什么时候应该采用N → ε进行分析呢？我们观察产生式右侧所有出现N的地方，倘若N是空字符串，那么N后面的字符就会直接出现，也就是逗号和右括号。于是这就是我们的分支预测：

1. 如果超前查看遇到英文字母，预测分支N → a(N, N)
2. 如果超前查看遇到逗号、右括号预测分支N → ε

转化成代码就是这样：

Node ParseNode()
{
    int lookAheadIndex = m_index;

    char lookAheadChar = m_inputString[lookAheadIndex];

    if (Char.IsLetter(lookAheadChar))
    {
        //采用N → a(N, N)继续分析
    }
    else if (lookAheadChar == ',' || lookAheadChar == ')' )
    {
        //采用N → ε继续分析
    }
    else
    {
        throw new Exception("语法错误");
    }
}

接下来我们分别来看两个分支怎么处理。先来看N → ε，这种情况下非终结符是个空字符串，所以我们不需要移动当前索引，直接返回null表示空节点。再来看N → a(N, N) 分支，倘若输入的字符串没有任何语法错误，那就应该依次遇到字母、左括号、N、逗号、N右括号。根据上面的规则，凡是遇到终结符，就移动当前索引，直接向前扫描；而要是遇到非终结符，就递归调用相应节点的方法。所以（不考虑语法错误）的完整方法代码如下：

<Node ParseNode()
{
    int lookAheadIndex = m_index;

    char lookAheadChar = m_inputString[lookAheadIndex];

    if (Char.IsLetter(lookAheadChar))
    {
        //采用N → a(N, N)继续分析
        char label = m_inputString[m_index++]; //解析字母
        m_index++; //解析左括号，因为不需要使用它的值，所以直接跳过

        Node left = ParseNode(); //非终结符N，递归调用

        m_index++; //解析逗号，跳过

        Node right = ParseNode(); //非终结符N，递归调用

        m_index++; //解析右括号，跳过

        return new Node(label, left, right);
    }
    else if (lookAheadChar == ',' || lookAheadChar == ')')
    {
        //采用N → ε继续分析
        //无需消耗输入字符，直接返回null
        return null;
    }
    else
    {
        throw new Exception("语法错误");
    }
}

因为存在语法约束，所以一旦我们完成了分支预测，就能清楚地知道下一个字符或非终结符一定是什么，无需再进行任何判断（除非要进行语法错误检查）。因此根本就不需要寻找逗号在什么位置，我们解析到逗号时，逗号一定就在那，这种感觉是不是很棒？只需要寥寥几行代码就已经写出了一个完整的Parser。大家感兴趣可以继续补全一些辅助代码，然后用真正的字符串输入试验一下，是否工作正常。前面假设输入字符串的语法是正确的，但真实世界的程序总会写错，所以编译器需要能够帮助检查语法错误。在上述程序中加入语法错误检查非常容易，只要验证每个位置的字符，是否真的等于产生式中规定的终结符就可以了。这就留给大家做个练习吧。

上面我们采用的分支预测法是“人肉观察法”，编译原理书里一般都有一些计算FIRST集合或FOLLOW集合的算法，可以算出一个产生式可能开头的字符，这样就可以用自动的方法写出分支预测，从而实现递归下降语法分析器的自动化生成。ANTLR就是用这种原理实现的一个著名工具。有兴趣的同学可以去看编译原理书。其实我觉得“人肉观察法”在实践中并不困难，因为编程语言的文法都特别有规律，而且我们天天用编程语言写代码，都很有经验了。

下面我们要研究一下递归下降法对文法有什么限制。首先，我们必须要通过超前查看进行分支预测。支持递归下降的文法，必须能通过从左往右超前查看k个字符决定采用哪一个产生式。我们把这样的文法称作LL(k)文法。这个名字中第一个L表示从左往右扫描字符串，这一点可以从我们的index变量从0开始递增的特性看出来；而第二个L表示最左推导，想必大家还记得上一篇介绍的最左推导的例子。大家可以用调试器跟踪一遍递归下降语法分析器的分析过程，就能很容易地感受到它的确是最左推导的（总是先展开当前句型最左边的非终结符）。最后括号中的k表示需要超前查看k个字符。如果在每个非终结符的解析方法开头超前查看k个字符不能决定采用哪个产生式，那这个文法就不能用递归下降的方法来解析。比如下面的文法：

F → id
F → ( E )
E → F * F
E → F / F

当我们编写非终结符E的解析方法时，需要在两个E产生式中进行分支预测。然而两个E产生式都以F开头，而且F本身又可能是任意长的表达式，无论超前查看多少字符，都无法判定到底应该用乘号的产生式还是除号的产生式。遇到这种情况，我们可以用提取左公因式的方法，将它转化为LL(k)的文法：

F → id
F → ( E )
G → * F
G → / F
E → FG

我们将一个左公因式F提取出来，然后将剩下的部分做成一个新的产生式G。在解析G的时候，很容易进行分支预测。而解析E的时候则无需再进行分支预测了。在实践中，提取左公因式不仅可以将文法转化为LL(k)型，还能有助于减少重复的解析，提高性能。

下面我们来看LL(k)文法的第二个重要的限制——不支持左递归。所谓左递归，就是产生式产生的第一个符号有可能是该产生式本身的非终结符。下面的文法是一个直截了当的左递归例子：

F → id
E → E + F
E → F

这个表达式类似于我们上篇末尾得到的无歧义二元运算符的文法。但这个文法存在左递归：E产生的第一个符号就是E本身。我们想像一下，如果在编写E的递归下降解析函数时，直接在函数的开头递归调用自己，输入字符串完全没有消耗，这种递归调用就会变成一种死循环。所以，左递归是必须要消除的文法结构。解决的方法通常是将左递归转化为等价的右递归形式：

F → id
E → FG
G → + FG
G → ε

大家应该牢牢记住这个例子，这不仅仅是个例子，更是解除大部分左递归的万能公式！我们将要在编写miniSharp语法分析器的时候一次又一次地用到这种变换。

由于LL(k)文法不能带有左递归和左公因式，很多常见的文法转化成LL(k)之后显得不是那么优雅。有许多程序员更喜欢使用LR(k)文法的语法分析器。LR代表从左到右扫描和最右推导。LR型的文法允许左递归和左公因式，但是并不能用于递归下降的语法分析器，而是要用移进-归约型的语法分析器，或者叫自底向上的语法分析器来分析。我个人认为LR型语法分析器的原理非常优雅和精妙，但是限于本篇的定位我不准备介绍它。我想任何一本编译原理书里都有详细介绍。当然如果未来我的VBF库支持了LR型语法分析器，我也许会追加一些特别篇，谁知道呢？

希望大家看了今天这篇文章之后，都能用递归下降法写出一些LL(k)文法的语法分析器来。下一篇我将介绍使用C#和VB中神奇的Linq语法来“组合”出语法分析器来，敬请期待！

希望大家继续关注我的VBF项目：https://github.com/Ninputer/VBF 和我的微博：http://weibo.com/ninputer 多谢大家支持！