前曾經為Parser Combinator寫過一篇教程。這次為了處理Vczh Library++新設計的ManagedX托管語言，我為Parser Combinator新增了三個組合子。
第一個是def，第二個是let。它們組合使用。def(pattern, defaultValue)的意思是，如果pattern成功了那麼返回pattern的分析結構，否則返回defaultValue。let(pattern, value)的意思是，如果pattern成功了則返回value，否則失敗。因此他們可以一起使用。舉個例子，ManagedX跟C#一樣具有5種type accessor：public, protected, protected internal, private, internal。其中四種accessor的文法類型是token，剩下的protected internal則是tuple<token, token>。因此我們無法很方便地為它寫一個記號到語法樹的轉換函數。而且對於缺省情況要返回private的這種行為，在EBNF+handler上直接表達出來也比較困難。當def和let還不存在的時候，我們需要這麼寫：
accessor = (PUBLIC[ToAccessor] | PROTECTED[ToAccessor] | PRIVATE[ToAccessor] | INTERNAL[ToAccessor] | (PROTECTED + INTERNAL)[ToProtectedInternal])[ToAccessorWithDefault];
這個時候我們需要創建三個函數，分別是ToAccessor、ToProtectedInternal和ToAccessorWithDefault。因為accessor本身不是一個重要的語法元素，所以我們不需要為accessor記錄一些源代碼的位置信息。表達式則需要位置信息，這可以在我們產生錯誤信息的時候知道錯誤發生在源代碼中的位置。而accessor總是直接屬於某一個重要的語法元素的，所以不需要保存。如果不需要保存位置信息的話，那麼一個ToXXX的函數其實就是沒有必要的。這個時候可以讓def和let來簡化操作：
accessor = def(let(PUBLIC, acc::Public) | let(PROTECTED, acc::Protected) | let(PRIVATE, acc::Private) | let(INTERNAL, acc::Internal) | let(PROTECTED+INTERNAL, acc::ProtectedInternal), acc::Private);
看起來好像差不多，但實際上我們已經減少了那三個不需要存在的函數。
============================無恥的分割線====================================
第三個是binop。做這個主要是因為那個通用的lrec（左遞歸組合子）在對付帶大量括號的表達式的時候性能表現不好。這裡稍微解釋一下原因。假設我們的語言有>、+、*和()四種操作符，那文法一般都寫成：
exp0 = NUMBER | ( exp3 )
exp1 = exp1 * exp0 | exp0
exp2 = exp2 + exp1 | exp1
exp3 = exp3 > exp2 | exp2
因此可以很容易的知道，當我們分析1*2*3的時候，走的是下面的路子：
exp3
= exp2
= exp1
= exp1 * exp0
= exp1 * exp1 * exp0
= 1 * 2 * 3
現在我們做一個簡單的變換，把1*2*3變成((1*2)*3)。意義不變，但是分析的路徑卻完全改變了：
exp3
= exp2
= exp1
= exp0
= ( exp3 )
= ( exp2 )
= ( exp1 )
= ( exp1 * exp0 )
= ( exo0 * exp0 )
= ( ( exp3 ) * exp0 )
= ( ( exp2 ) * exp0 )
= ( ( exp1 ) * exp0 )
= ( ( exp1 * exp0 ) * exp0 )
= ( ( exp0 * exp0 ) * exp0 )
= ( ( 1 * 2 ) * 3 )
咋一看好像沒什麼區別，但是對於ManagedX這種有十幾個優先級的操作符的語言來說，如果給一個復雜的表達式的每一個節點都加上括號，等於一下子增加了上千層文法的遞歸分析。由於Parser Combinator是遞歸向下分析器，因此路徑有這麼長，那麼遞歸的層次也會有這麼長。而且為了避免boost::Spirit那個天殺的超慢編譯速度的問題，這裡犧牲了一點點性能，將組合字的Parse函數做成了虛函數，所以編譯速度提高了超多。一般來說一個需要編譯一個半小時的boost::Spirit語法分析器用我的庫只需要幾秒鐘就可以編譯完了。不過現在卻帶來了問題。括號一多，性能下降的比較明顯。但是我們顯然不能因噎廢食，因此我決定往Parser Combinator提供一個手寫的帶優先級的左右結合一二元操作符語法分析器。為了將這個手寫的分析器插入框架並變得通用，我決定采用下面的結構。下面的代碼是從ManagedX的語法分析器中截取出來的： 1 expression = binop(exp0)
2 .pre(ADD_SUB, ToPreUnary).pre(NOT_BITNOT, ToPreUnary).pre(INC_DEC, ToPreUnary).precedence()
3 .lbin(MUL_DIV_MOD, ToBinary).precedence()
4 .lbin(ADD_SUB, ToBinary).precedence()
5 .lbin(LT << LT, ToBinaryShift).lbin(GT >> GT, ToBinaryShift).precedence()
6 .lbin(LT, ToBinary).lbin(LE, ToBinary).lbin(GT, ToBinary).lbin(GE, ToBinary).precedence()
7 .post(AS + type, ToCasting).post(IS + type, ToIsType).precedence()
8 .lbin(EE, ToBinary).lbin(NE, ToBinary).precedence()
9 .lbin(BITAND, ToBinary).precedence()
10 .lbin(XOR, ToBinary).precedence()
11 .lbin(BITOR, ToBinary).precedence()
12 .lbin(AND, ToBinary).precedence()
13 .lbin(OR, ToBinary).precedence()
14 .lbin(QQ, ToNullChoice).precedence()
15 .lbin(QT + (expression << COLON(NeedColon)), ToChoice).precedence()
16 .rbin(OPEQ, ToBinaryEq).rbin(EQ, ToAssignment).precedence()
17 ;
binop組合子的參數代表整個帶優先級的最高優先級表達式組合字（參考上面給出的>+*()文法，可以知道這裡的exp0是什麼意思）。binop給出了四個子組合子，分別是pre（前綴一元操作符）、post（後綴一元操作符）、lbin（左結合二元操作符）和rbin（右結合二元操作符）。precedence代表一個優先級的所有操作符定義結束。這裡我做了一個小限制，也就是每一個precedence只能包含pre、post、lbin和rbin的其中一種。實踐表明這種限制不會帶來任何問題。因此這裡我們得到了一張操作符和優先級的關系表。到了這裡我們就可以在Parser Combinator的框架下寫一個手寫的語法分析器（下載源代碼並打開LibraryCombinator\_Binop.h）來做了。至於如何手寫語法分析器，我之前給出了一篇文章，大家可以參考這個來閱讀_Binop.h。
binop比起簡單的用lrec做同樣的事情，性能在debug下提高了100多倍，release下面則少一點。到了這裡，Parser Combinator重新滿足了性能要求，我們可以放心大膽的用一點點無所謂的性能換取一千多倍的編譯時間了。在這裡貼出當binop還沒出現的時候我用lrec給出的操作符文法的實現： 1 exp1 = exp0
2 | ((ADD_SUB | NOT_BITNOT | INC_DEC) + exp1)[ToUnary]
3 ;
4
5 exp2 = lrec(exp1 + *((MUL_DIV_MOD + exp1)[ToBinaryLrec]), ToLrecExpression);
6 exp3 = lrec(exp2 + *((ADD_SUB + exp2)[ToBinaryLrec]), ToLrecExpression);
7 exp4 = lrec(
