有兩個星期沒有更新博客了，主要是最近在研究一種更靈活的代碼編輯框的框架設計，修了很多bug，還有公司的事情多了起來。現在全部都解決了，因此開始寫這一篇博客。上一篇文章提到了我搞定了一個智能提示的原型，當然現在已經在Vczh Library++ 3.0上面添加了鼠標指向一個對象顯示聲明代碼和打括號的時候提示函數參數（部分完成）的功能了。今天來說一下我是如何實現這些功能的。當然我不會講所有細節，只會講重點，如何實現那個界面也不包括在這里。我要說的是，如何立刻知道任意一個位置所在的代碼究竟是什么東西。

    如果你沒有讀過之前的幾篇文章的話，建議去翻一翻，因為我之前提到了一些背景，還有我實現的C#版yacc（當然只是指功能，并不兼容），IDE和編譯器的語法分析器的異同和實現一個IDE用的語法分析器要注意的地方。

    語法分析總是產生語法樹或者分析樹的，無論開發什么能夠感應代碼內容的工具，都逃不過語法分析。因此可以肯定的是，在你敲代碼的時候，IDE真的在背后生成了一棵樹，只不過為了要達到普通文本框的輸入性能，很多東西都要移動到后臺去做，但是為了瞬間響應并作智能提示，有一些東西要移動到前臺做。他們之間的分界線想要界定清楚其實也不是很難。

    假設我們要編輯一份超大文件（幾萬行吧，再超過要開除的哈），每當你打字修改它的時候，一定會進行語法分析并產生語法樹。對于這么大規模的代碼要產生語法樹肯定不是瞬間就能完成的（我那個東西大概要一秒鐘多一點），因此這一步是在后臺完成的。但是當你打一個"."的時候，你肯定希望立刻就要彈出列表的內容。為了知道列表的內容，你肯定得先知道那個"."出現在了什么表達式里面，以及"."前面的那個表達式究竟是什么類型，這是離不開全文分析的。但是全文分析又太慢，所以我引入了一個技術。

    為了完成這個技術，你必須在前臺分析得到那個表達式。我們很容易就知道，我們是不可能等待后臺分析給我們提供數據的。所以在這里我們要做的是，緩存當前我們感興趣的代碼。在這里簡單化一下，如果我們只需要提供按"."彈出列表的話，我們只需要緩存語句（statement）就可以了。怎么做呢？假設我們已經可以通過所在的位置得到代碼的內容（下面會講），那么我們顯然可以知道光標的位置所在的語句的語法樹對象究竟是什么。有了這個語法樹對象，我們就可以從代碼里面直接把這個語句的代碼文字復制出來，然后緩存語句的代碼、語句所在的全文位置和語句所在的作用域。作用域是語法樹的一部分，在做完語法分析之后，只需要做簡單的語義分析建立作用域就可以計算很多東西了。這個緩存會在光標位置移動的時候更新，也會在當前的全文分析結束的時候更新。

    一旦緩存下來之后，你往里面打了一個字符，那我不僅可以更新文本框里面的內容，我還可以更新緩存里面的代碼的內容，同時還可以知道新的緩存開始結束位置。一個語句通常都是很短的，最多也就一百來個字符，因此我們立刻在前臺對它做語法分析。而且往一個語句里面打字的話，99%以上的情況是不會影響到上下文的，所以這個語句的舊作用域對象仍然可用。這個時候我們用舊的作用域對象來對新的語句做語義分析，那么就可以知道這個語句每一個表達式的類型了，從而知道了"."前面的表達式究竟是什么類型。然后利用舊作用域對象，我們就可以知道這個類型包含了多少成員。到了這一步，列表里面的對象就構造完畢了。

    然而后臺的全文分析總是會結束的，所有的信息在這個時候就準備好了，然后發個消息給前臺讓它更新緩存。兩種更新緩存都是用GUI的消息驅動的，所以不可能同時發生，只會先后發生。之前談到的臨時更新跟后臺的全文分析是并行的，不過這個不會影響我們。只要我們正確處理后臺跟前臺的信息交換，那么整個智能感應的計算過程就可以做得十分安全，不會發生死鎖。我相信這一點應該不是很難。

    那么，現在回到了兩個最原始的問題。第一個是如何通過位置查找語法樹。這個很容易解決，只要在語法分析的時候把所有跟位置有關的信息都記錄在樹里面就可以了。第二個問題是我們如何處理用戶寫錯的代碼。平時編譯原理里面所教授的自動錯誤恢復其實是不好用的，你看看VC++的編譯器在你寫錯了什么東西之后，大部分的錯誤信息基本上都沒法看，因此如何進行錯誤恢復肯定要我們自己進行精心設計。但是問題來了，我們如何實現它呢？顯然手寫語法分析器會讓我們心煩意亂根本做不下去（還要處處記得記錄位置信息……），因此我們需要一個語法分析器生成器。

    在這里我建議大家去閱讀我博客上的兩篇文章，你可以從這兩篇文章所給的鏈接看到一些其他的東西，講的是如何用組合子開發語法分析器。我這里給語法樹添加了一個新屬性，也就是一種組合起來強大但是又容易指定的錯誤恢復技術了。這里的錯誤恢復技術分為兩種，一種是針對循環的，這個大家看代碼就可以了，因為跟第二種——也就是序列關系的文法的錯誤恢復——非常相似，只是一個理論上的變換而已。

    內容是這樣的。假設我們需要分析下面的表達式：EXPRESSION + "." + MEMBER，那么我們總是希望在殘缺不全的代碼里面恢復出盡可能正確的信息。我們知道一旦出現了"."，用戶想要寫的必然是一個訪問對象成員的表達式，因此我們在"."那里表上記號，變成EXPRESSION + "." + MEMBER。標記有一個副作用，也就是一旦標記所包含的語法分析成功了，那么整條語法會保證產生出指定的語法樹結構。如果用戶出現了錯誤，那么所有的錯誤都會被當成用戶少輸入了什么東西而引起的。雖然這一個假設對于編譯器來說不太合適，但是對于IDE來說顯然是合適的。但是這種做法很容易在分析列表結構的代碼里引起死循環，所以需要做很多測試來保證你的標記不會造成問題。

    下面的例子也可以輔助說明這種方法的有效性。舉個例子，你需要做一個函數。你在寫函數的過程中顯然會臨時或者不小心少些一些東西——有時候我們并不是把所有的事情都想清楚了才開始寫代碼的。這個時候為了正確分析出函數的結構，我們做下面的語法并標記：
    FUNCTION_DECLARATION ::= TYPE + NAME + "(" + list<TYPE + NAME, ","> + ")" + COMPOSITE_STATEMENT
    VARIABLE_DECLARATION ::= TYPE + NAME + optional("=" + EXPRESSION) + ";"
    然后總是保證FUNCTION_DECLARATION的優先級比VARIABLE_DECLARATION更高，我們就總是可以恢復出最正確的語法結構了。這一種做法對于你在連續輸入代碼的過程中進行正確的提示是相當好用而且方便的。

    至于代碼生成器本身怎么實現，還是去Vczh Library++ 3.0下載代碼吧。