一、释名

　　为什么叫精神？
　　如果你熟悉c++，那么你可能知道一个叫做”spirit”的parser库。它利用c++的模板元编程能力，使用c++语言本身提供了一个递归下降文法解析的框架。

　　我这里介绍的jparsec库，就是一个java里面的递归下降文法解析框架。
　　不过，它并非是spirit的java版本。

　　jparsec的蓝本来自haskell语言的parsec库。parsec是一个基于monad的parser组合子库。

　　这个库的目的是要在java中提供一个类似parsec, spirit的库，这种组合子库并非c++的专利，java/c#也可以做到。这个库还将在java5.0上被改写，类型安全上它将也不再逊色于c++。

　　那么，为什么叫“函数式”呢？java是面向对象的嘛。
　　如果你使用过haskell, lisp等语言，这个函数式不用解释你也知道是怎么回事了。
　　如果你是一个老牌的c++/java程序员，那么这里还要稍微解释一下。当然如果您对这些虚头八脑的名词不感兴趣，那么，你尽可以跳过这一章，不知道什么是“函数式”，并不会影响你对这个库的理解的。

　　c++这几年随着gp的普及，“函数式”这个老孔乙己逐渐又被人从角落里面拽了出来。一个c++程序员所熟悉的“函数式”很可能是stl的for_each, transform，count_if这些函数。
　　怎么说呢，就象我不能否定str.length()这个调用属于oo一样，我也无法说for_each, transform不是函数式。

　　但是，“函数式”的精髓不在于此。

　　一般归纳起来，就像我们说oo是什么多态，封装，继承一样，“函数式”的特征被总结为：

　　1.无副作用。
　　2.高阶函数。
　　3.延迟计算

　　而最最有意义的（至少我认为如此），是基于高阶函数的函数组合能力。一些人把这叫做glue。
　　简短地说，什么让函数式编程如此强大？是用简单的函数组合出复杂函数的能力。

　　我可以想象，说到这里，你还是一头雾水。“什么是组合？1+1不是也把两个1组合成2了吗？new a(new b(), new c())不也是从b和c组合成a了？”

　　为了直观，我们来举个例子吧。
　　假设，我们在package predicates内部有一个接口：

interface spredicate{ 　　boolean is(string s); 　　}

　　我们有几个基本的实现：

class isempty implements spredicate{ 　　public boolean is(string s){return s.length()==0;} 　　}

　　这个实现判断字符串是不是空。

class iscaptialized implements spredicate{…}

　　这个实现判断这个字符串是不是大写打头。

class islowercase implements spredicate{…}

　　这个实现判断字符串是不是全小写。

class isequal implements spredicate{ 　　private final string v; 　　public boolean is(string s){return s.equals(v);} 　　isequal(string v){this.v = v;} 　　}

　　这个实现判断这个字符串是否和制定的字符串相等。

　　类似的基本实现还可以有很多。

　　下面，假如我们希望实现一个spredicate，它要判断“这个字符串是个小写字符串，或者等于hello”。
　　我们怎么办呢？

　　我们当然可以这样：

class predicate1 implements spredicate{ 　　boolean is(string v){ 　　return v.islowercase() || v.equals(“hello”); 　　} 　　}

　　只不过，这样一来，我们没有重用isequal和islowercase这两个类的代码，虽然逻辑上我们是和这两个类有重叠。

　　我们当然也可以直接调用isequal和islowercase的代码，如：

class predicate1 implements spredicate{ 　　boolean is(string v){ 　　return new isequal().is(v) || new islowercase().is(v); 　　} 　　}

　　只不过，这样的代码是过程式的，非常死板。
　　如果我再有一个isequal或者iscapitalized的逻辑呢？还要再写一个predicate2类么？
　　如果你oo有一定功底，一定可以看出，这个代码不符合ioc原则，在不该new的地方new了。

　　好，知错就改，根据ioc原则，我们重构如下：

class orpredicate implements spredicate{ 　　private final spredicate p1; 　　private final spredicate p2; 　　public boolean is(string s){ 　　return p1.is(s) || p2.is(s); 　　} 　　}

　　构造函数我就不写了。

　　如此，predicate1我们就可以写成new orpredicate(new islowercase(), new isequal(“hello”));

　　类似的，我们可以加上andpredicate, notpredicate, xorpredicate.
　　这样，基本上就可以覆盖所有的布尔操作了。

　　我们在写我们自己的predicate的时候，就根本不必写is函数，甚至可以忘记is函数的存在。我们面对的不再是一个有着一个boolean is(string)签名的接口，而是一个可以通过各种规则组合的类型。

　　一个predicate可以简单如new notpredicate(p)，也可以复杂如：

new andpredicate(new orpredicate(a,new xorpredicate(b,c), d));

　　擦擦眼睛，现在，我们等于自己制造出一个可以用一些特定规则组合的类型，而spredicate的签名甚至都不再重要了。我们的客户程序从操作字符串变成了操作各种spredicate对象，这已经是更高一级的抽象了。

　　为了表现这一点，让我们把spredicate改成abstract class, 并把is()函数改成包私有（这样我们外面的用户程序就再也看不到这个函数了）。

　　等等！你可能发现了，现在我们虽然可以自由组合不同的spredicate对象，但是组合之后有什么用呢？is函数看不见了，难道我们就是为了组合而组合吗？
　　不错，一个完整的组合子，还缺最后一小块。

　　让我们在predicates包内部再加上一个utility函数：

public boolean runpredicate(spredicate p, string s){ 　　return p.is(s); 　　}

　　好了，功德圆满，我们可以用这个runpredicate函数来执行一个组合好了的spredicate对象，而不用关心这个对象内部的is函数。

　　你可能有点怀疑。runpredicate(p, s)和p.is(s)有什么区别？

　　呵呵，现在是没什么区别。下面我们来看看什么时候这种封装有明显的好处。
　　假设根据实现需要我们的spredicate.is函数不是现在看到的这么简单，它可能是：
　　boolean is(string s, predicatecontext ctxt);
　　predicatecontext对象负责存储并传递一些包局部的信息。
　　此时，我们很有可能不希望把这个签名对外公布。因为这个签名非常有可能变化，它是一个包的实现细节。predicatecontext甚至都是个包私有的类型。

　　此时，把is函数隐藏起来就是必要的了。对外，我们只公开一个runpredicate工具函数：

public boolean runpredicate(string s, spredicate p){ 　　final predicatecontext ctxt = new predicatecontext(); 　　return p.is(s, ctxt); 　　}

　　好，现在客户程序可以随意组合各个predicate对象，最后用runpredicate函数运行。而包内部在演化时，完全可以根据需要随时改动is函数的签名，增加新的状态。

　　这，就是一个完整的组合子的例子。