其實Vczh Library++3.0提供的parser combinator并不能大量減少語法分析器的代碼量，其實真正降低的是語法分析器的復雜程度。當你想比較快速的完成一個功能的時候，有兩種代碼量差不多的設計，一種實現起來比較難并且調試起來很慘，一種實現起來比較簡單而且基本不用怎么調試，那相對來說肯定會選擇后一種方法了。除非你純粹是想獲得鍛煉。

    使用parser combinator開發語法分析器的時候，你可以直接往C++里面寫EBNF語法，當然語法的具體形式因為受到C++語言本身的限制我做了一點點修改，譬如說A*和A+只好寫成*A和+A，A B只好寫成A + B、A>>B或者A<<B了。空明流產跟我抱怨說boost::spirit編譯速度奇慢（據說要一個多小時，不知道是不是他機器太爛……）而且容易出現C1060 compiler is out of heap space的錯誤，相比之下我在用我自己開發的parser combinator的時候，我一個充滿語法的cpp文件只需要一秒多一點（Thinkpad R61i, Vista Home Basic, 3G內存），而且不會出現C1060這種離譜的錯誤。至少從這個程度上來說，開發boost::spirit的人應該是有很大的C++潔癖癥，才會把好好地一個parser combinator折騰成那個樣子。

    我是用的文法模型是帶類型修飾的文法，從文法的類型只能看出文法最終給你什么數據，而不是文法他本身是怎么寫的。Vczh Library++2.0的parser combinator采用了后面一中的做法，據說boost::spirit也是這么做的，不過奇怪的是舊的parser combinator也沒出現那兩種錯誤，取而代之是VC++經常抱怨我一個表達式的類型簽名超過了4000個字符（囧）。于是Vczh Library++3.0的parser combinator做了一點修改。

    假設你一條文法A的結果是node<input, type>，第二條文法B的結果是node<input, string>，那么A+B的結果就是node<input, pair<type, string>>。這是什么意義呢？我們看表達文法type name semicolon的意思，大概可以理解為他可以接受“int a;”的這種語句。首先由于C++的限制我們替換成type + name + semicolon，其次由于那個semicolon，也就是分號，其實僅僅是語法的要求而不是語法樹的一個必須成分，因此改成type + name << semicolon。這樣的話，這個文法依舊會要求輸入的字符串分別是一個類型、一個名字和一個分號，但是返回的結果就自動把分號給忽略掉了。那么我們如何表示一個同時包含type和name的類型呢？因為文法不可能替你創建一個struct，所以就定義了一個泛型的pair來表達。于是type + name << semicolon的結果類型就是node<input, pair<type, string>>了。這里input代表輸入的記號列表的類型。

    上面是新的parser combinator的做法，舊的parser combinator（據說也是boost::spirit的做法）的類型表示方法比較BT：當你有文法type : node<input, type>，string : node<input, string>和semicolon : node<input, token>的話，那么type + name << semicolon的類型會變成：
    寫成這樣大概就可以理解什么是“文法他本身是怎么寫的”了吧。

    舊的parser combinator的好處是C++為每一個文法生成了一個類型，雖然代碼會膨脹一點但是執行過程會很快，只不過缺點比較多。第一個當然是類型太多VC++編譯器會崩潰（C1060 compiler is out of heap space），第二個是編譯時間過長，第三個是當你的文法比較長的時候，類型簽名可能會超過VC++給你的限制，然后就會出現奇怪的問題。所以我在Vczh Library++3.0的parser combinator就是用了一個新的做法，也就是僅保留文法的結果類型，所以也就不得不引入虛函數了。因為一個文法node<input, type>有非常多種組合可能，在結構上沒辦法表現出來，所以必須使用虛函數。

    在聽了空明流產的抱怨之后，我去搜了一下使用boost::spirit的人的反應，好像都是遇到了那兩個嚴重的問題。幸好我喜歡造車輪，不然的話也許也會深陷地獄了。不過boost::spirit還是提供了解決辦法的，就是把你的長的文法拆開成短的。寫過編譯器的人都會知道，這么做的嚴重后果就是你的分析器變成一團亂麻，根本不知道自己在寫什么，不僅不可能有我上一篇文章描寫的優美結果，更不可能把NativeX的分析器寫成下面這個樣子了：

    啊，簡直就跟EBNF沒什么區別啊。

    當前的進度可以在Vczh Library++3.0的頁面上看到。