其實(shí)Vczh Library++3.0提供的parser combinator并不能大量減少語(yǔ)法分析器的代碼量，其實(shí)真正降低的是語(yǔ)法分析器的復(fù)雜程度。當(dāng)你想比較快速的完成一個(gè)功能的時(shí)候，有兩種代碼量差不多的設(shè)計(jì)，一種實(shí)現(xiàn)起來(lái)比較難并且調(diào)試起來(lái)很慘，一種實(shí)現(xiàn)起來(lái)比較簡(jiǎn)單而且基本不用怎么調(diào)試，那相對(duì)來(lái)說(shuō)肯定會(huì)選擇后一種方法了。除非你純粹是想獲得鍛煉。

    使用parser combinator開(kāi)發(fā)語(yǔ)法分析器的時(shí)候，你可以直接往C++里面寫(xiě)EBNF語(yǔ)法，當(dāng)然語(yǔ)法的具體形式因?yàn)槭艿紺++語(yǔ)言本身的限制我做了一點(diǎn)點(diǎn)修改，譬如說(shuō)A*和A+只好寫(xiě)成*A和+A，A B只好寫(xiě)成A + B、A>>B或者A<<B了。空明流產(chǎn)跟我抱怨說(shuō)boost::spirit編譯速度奇慢（據(jù)說(shuō)要一個(gè)多小時(shí)，不知道是不是他機(jī)器太爛……）而且容易出現(xiàn)C1060 compiler is out of heap space的錯(cuò)誤，相比之下我在用我自己開(kāi)發(fā)的parser combinator的時(shí)候，我一個(gè)充滿語(yǔ)法的cpp文件只需要一秒多一點(diǎn)（Thinkpad R61i, Vista Home Basic, 3G內(nèi)存），而且不會(huì)出現(xiàn)C1060這種離譜的錯(cuò)誤。至少?gòu)倪@個(gè)程度上來(lái)說(shuō)，開(kāi)發(fā)boost::spirit的人應(yīng)該是有很大的C++潔癖癥，才會(huì)把好好地一個(gè)parser combinator折騰成那個(gè)樣子。

    我是用的文法模型是帶類型修飾的文法，從文法的類型只能看出文法最終給你什么數(shù)據(jù)，而不是文法他本身是怎么寫(xiě)的。Vczh Library++2.0的parser combinator采用了后面一中的做法，據(jù)說(shuō)boost::spirit也是這么做的，不過(guò)奇怪的是舊的parser combinator也沒(méi)出現(xiàn)那兩種錯(cuò)誤，取而代之是VC++經(jīng)常抱怨我一個(gè)表達(dá)式的類型簽名超過(guò)了4000個(gè)字符（囧）。于是Vczh Library++3.0的parser combinator做了一點(diǎn)修改。

    假設(shè)你一條文法A的結(jié)果是node<input, type>，第二條文法B的結(jié)果是node<input, string>，那么A+B的結(jié)果就是node<input, pair<type, string>>。這是什么意義呢？我們看表達(dá)文法type name semicolon的意思，大概可以理解為他可以接受“int a;”的這種語(yǔ)句。首先由于C++的限制我們替換成type + name + semicolon，其次由于那個(gè)semicolon，也就是分號(hào)，其實(shí)僅僅是語(yǔ)法的要求而不是語(yǔ)法樹(shù)的一個(gè)必須成分，因此改成type + name << semicolon。這樣的話，這個(gè)文法依舊會(huì)要求輸入的字符串分別是一個(gè)類型、一個(gè)名字和一個(gè)分號(hào)，但是返回的結(jié)果就自動(dòng)把分號(hào)給忽略掉了。那么我們?nèi)绾伪硎疽粋€(gè)同時(shí)包含type和name的類型呢？因?yàn)槲姆ú豢赡芴婺銊?chuàng)建一個(gè)struct，所以就定義了一個(gè)泛型的pair來(lái)表達(dá)。于是type + name << semicolon的結(jié)果類型就是node<input, pair<type, string>>了。這里input代表輸入的記號(hào)列表的類型。

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

    舊的parser combinator的好處是C++為每一個(gè)文法生成了一個(gè)類型，雖然代碼會(huì)膨脹一點(diǎn)但是執(zhí)行過(guò)程會(huì)很快，只不過(guò)缺點(diǎn)比較多。第一個(gè)當(dāng)然是類型太多VC++編譯器會(huì)崩潰（C1060 compiler is out of heap space），第二個(gè)是編譯時(shí)間過(guò)長(zhǎng)，第三個(gè)是當(dāng)你的文法比較長(zhǎng)的時(shí)候，類型簽名可能會(huì)超過(guò)VC++給你的限制，然后就會(huì)出現(xiàn)奇怪的問(wèn)題。所以我在Vczh Library++3.0的parser combinator就是用了一個(gè)新的做法，也就是僅保留文法的結(jié)果類型，所以也就不得不引入虛函數(shù)了。因?yàn)橐粋€(gè)文法node<input, type>有非常多種組合可能，在結(jié)構(gòu)上沒(méi)辦法表現(xiàn)出來(lái)，所以必須使用虛函數(shù)。

    在聽(tīng)了空明流產(chǎn)的抱怨之后，我去搜了一下使用boost::spirit的人的反應(yīng)，好像都是遇到了那兩個(gè)嚴(yán)重的問(wèn)題。幸好我喜歡造車輪，不然的話也許也會(huì)深陷地獄了。不過(guò)boost::spirit還是提供了解決辦法的，就是把你的長(zhǎng)的文法拆開(kāi)成短的。寫(xiě)過(guò)編譯器的人都會(huì)知道，這么做的嚴(yán)重后果就是你的分析器變成一團(tuán)亂麻，根本不知道自己在寫(xiě)什么，不僅不可能有我上一篇文章描寫(xiě)的優(yōu)美結(jié)果，更不可能把NativeX的分析器寫(xiě)成下面這個(gè)樣子了：

    啊，簡(jiǎn)直就跟EBNF沒(méi)什么區(qū)別啊。

    當(dāng)前的進(jìn)度可以在Vczh Library++3.0的頁(yè)面上看到。