Vczhl Library++3.0之Parser Combinator為常見的語法結構做優化
阿新 • • 發佈:2018-12-27
之前曾經為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的框架下寫一個手寫的語法分析器(下載原始碼並開啟Library\Combinator\_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(exp3 +*((((LT << LT) | (GT >> GT)) + exp3)[ToBinaryShiftLrec]), ToLrecExpression);
8 exp5 = lrec(exp4 +*(((LT | LE | GT | GE) + exp4)[ToBinaryLrec] | (AS + type)[ToCastingLrec] | (IS + type)[ToIsTypeLrec]), ToLrecExpression);
9 exp6 = lrec(exp5 +*(((EE | NE) + exp5)[ToBinaryLrec]), ToLrecExpression);
10 exp7 = lrec(exp6 +*((BITAND + exp6)[ToBinaryLrec]), ToLrecExpression);
11 exp8 = lrec(exp7 +*((XOR + exp7)[ToBinaryLrec]), ToLrecExpression);
12 exp9 = lrec(exp8 +*((BITOR + exp8)[ToBinaryLrec]), ToLrecExpression);
13 exp10 = lrec(exp9 +*((AND + exp9)[ToBinaryLrec]), ToLrecExpression);
14 exp11 = lrec(exp10 +*((OR + exp10)[ToBinaryLrec]), ToLrecExpression);
15 exp12 = lrec(exp11 +*((QQ + exp11)[ToNullChoiceLrec]), ToLrecExpression);
16 exp13 = lrec(exp12 +*((QT + (exp12 + (COLON(NeedColon) >> exp12)))[ToChoiceLrec]), ToLrecExpression);
17 expression = (exp13 + OPEQ + expression)[ToBinaryEq]
18 | (exp13 + EQ + expression)[ToAssignment]
19 | exp13
20 ;
21 22
第一個是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
看起來好像差不多,但實際上我們已經減少了那三個不需要存在的函式。
============================無恥的分割線====================================
第三個是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
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
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的框架下寫一個手寫的語法分析器(下載原始碼並開啟Library\Combinator\_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(exp3 +*((((LT << LT) | (GT >> GT)) + exp3)[ToBinaryShiftLrec]), ToLrecExpression);
8 exp5 = lrec(exp4 +*(((LT | LE | GT | GE) + exp4)[ToBinaryLrec] | (AS + type)[ToCastingLrec] | (IS + type)[ToIsTypeLrec]), ToLrecExpression);
9 exp6 = lrec(exp5 +*(((EE | NE) + exp5)[ToBinaryLrec]), ToLrecExpression);
10 exp7 = lrec(exp6 +*((BITAND + exp6)[ToBinaryLrec]), ToLrecExpression);
11 exp8 = lrec(exp7 +*((XOR + exp7)[ToBinaryLrec]), ToLrecExpression);
12 exp9 = lrec(exp8 +*((BITOR + exp8)[ToBinaryLrec]), ToLrecExpression);
13 exp10 = lrec(exp9 +*((AND + exp9)[ToBinaryLrec]), ToLrecExpression);
14 exp11 = lrec(exp10 +*((OR + exp10)[ToBinaryLrec]), ToLrecExpression);
15 exp12 = lrec(exp11 +*((QQ + exp11)[ToNullChoiceLrec]), ToLrecExpression);
16 exp13 = lrec(exp12 +*((QT + (exp12 + (COLON(NeedColon) >> exp12)))[ToChoiceLrec]), ToLrecExpression);
17 expression = (exp13 + OPEQ + expression)[ToBinaryEq]
18 | (exp13 + EQ + expression)[ToAssignment]
19 | exp13
20 ;
21 22