上一篇文章對大部分文法都構造出了一個使用的狀態機了，這次主要來講右遞迴的情況。右遞迴不像左遞迴那麼麻煩，因為大部分右遞迴寫成迴圈也不會過分的讓語法樹變得難以操作，不過仍然有少數情況是我們仍然希望保留遞迴的語法樹形狀，譬如C++的連等操作，因此這裡就來講一下這個問題。

右遞迴是怎麼形成的呢？在這裡我們先不想這個問題，我們來看一個普通的文法。在上一篇文章我們已經說過了，如果一條文法有一個非終結符引用了另一條文法，那麼就要做一條shift和reduce來從這個狀態機穿插到那個狀態機上：

在這裡需要講一下，綠色的箭頭是shift，紫色的箭頭是reduce，他們都是ε邊。更進一步說，如果A剛好以B作為結尾，那麼A的最後一個輸入就不是終結符輸入，不過因為她不是右遞迴，所以現在看起來還沒什麼問題：

我們已經接近右遞迴的形狀了。右遞迴的一個根本特徵當然是遞迴（廢話）。為了製作一個右遞迴，我們可以想一下，如果A和B不是兩個rule而是同一個rule會怎麼樣？當然咋這麼一看，好像就是A可以訪問自己了：

實際上這已經構成了一個ε邊的迴圈。左遞迴是shift的迴圈，右遞迴是reduce的迴圈，其實他們都一樣。那你可能會想，既然左遞迴和右遞迴只是相反的情況，為什麼左遞迴處理起來就那麼容易，右遞迴好像就沒什麼方法呢？其實如果你只是想要檢查一個字串是不是一個文法的其中一個元素而不建立語法樹的話，你完全可以把這條迴圈的ε reduce邊給壓縮成一條。為什麼呢？在之前講到，我們可以判斷一個reduce是不是由左遞迴造成的，我們也可以判斷一個shift是不是由右遞迴造成的。這種shift只要不壓狀態進棧，那麼右遞迴的reduce迴圈不管迴圈多少次，其實都是pop一個狀態出來，於是問題就沒有了。等價地，不處理語法樹的話，其實左遞迴也可以用相同的方法處理。

但是一旦當你涉及到建立語法樹的問題，你就等於給每一條邊都加上了一些semantic actions。這個時候shift和reduce就不是簡單地可以互相抵消的關係了，於是你就不能把一個迴圈的ε reduce邊壓縮成一條，那怎麼辦呢？

方法其實很簡單，只要我們在狀態機走著走著發現無路可走的時候，看看有沒有一條右遞迴reduce可以給我們“試一試”就好了。為什麼可以這樣做呢？我們還記得，當我們把整個狀態及壓縮到沒有ε邊的時候，每一個輸入都需要對堆疊的情況進行一次匹配。令人欣慰的事，沒有什麼邊可以跟右遞迴的reduce邊一樣產生同樣的匹配結構（但是我不想在這裡證明），所以這樣做是安全的。

到了這裡，我們已經把構造不帶lookahead狀態機的所有情況都說清楚了。一個文法如果需要構造lookahead的話，其實就等於在邊的匹配規則裡面加上一條對未來的一些token的要求，並沒有本質上改變語法分析的結構。但是我們知道，還有兩種上下文無關文法是不在這裡面的，C語言全佔了。我在這裡舉兩個簡單的例子：

變數宣告：對於一個已經typedef過的結構我們完全可以寫出這樣的程式碼：A*B;。這個時候A如果是型別，那這就需要走VariableDeclarationStatement的rule。如果A是一個表示式，那這就需要走ExpressionStatement的rule。但是對於語法分析來說，A就是一個簡單的token（除了typedef過的型別以外，所有C語言的型別都是以關鍵字開頭的，所以如果你們想做簡單的C語言的parser，就去掉typedef吧，啊哈哈哈哈），在語法分析的時候是無法做出預測的。

這種時候有兩種方法，第一種是準備更加豐富的semantic actions，讓符號表可以在parse的時候構造出來。那到了這裡，我們根據A究竟是不是一個型別，就可以賺到不同的分支上了。另一種就是，我們保留一個AmbiguousStatement的語法樹節點，把語法樹的一顆子樹遇到的不能處理的歧義的情況都寫進去。我們可能回想，為什麼我們不乾脆一個parser返回多個分析結果呢？因為如果不這麼做的話，一個函式裡面有10個這樣子的變數宣告，那你就有1024個結果了。如果我們把歧義收縮到一顆子樹上，那其實還是1個結果，只是多了10顆子樹，效果完全不同。

強制型別轉換：寫C語言的時候是不可能沒有強制型別轉換的，但是當parser看到類似這樣的程式碼的時候：(A*****)B，因為型別的結構和表示式的結構是不一樣的，但是你這個時候並不能在看到“(”的時候就做lookahead——因為這個lookahead是無限長的，括號裡面的表示式或者型別都可以無限長。不過就算你想把他侷限成有限長，就算你給100個token，那也會長出成千上萬種lookahead的模式，所以在這裡我們就不要用lookahead了。

那怎麼做呢？我們只需要把這個狀態機當成NDA（因為到了這裡他已經是NDA了），從deterministic push-down automaton變成了non-deterministic push-down automaton，我們也唯有讓我們的parser也變成non-deterministic了。關於這個內容，就等到下一篇——也就是這個系列的最後一篇文章——來詳細講解了。