LL(1)分析法和递归下降分析法同属于自顶向下分析法。相对于递归下降而言，LL通过显示
地维护一个栈来进行语法分析，递归下降则是利用了函数调用栈。
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、笼统来说，【觉得】太多东西没有意义，虽然并不真正懂这个东西。