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

    如果你沒有讀過之前的幾篇文章的話，建議去翻一翻，因?yàn)槲抑疤岬搅艘恍┍尘埃€有我實(shí)現(xiàn)的C#版yacc（當(dāng)然只是指功能，并不兼容），IDE和編譯器的語法分析器的異同和實(shí)現(xiàn)一個(gè)IDE用的語法分析器要注意的地方。

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

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

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

    一旦緩存下來之后，你往里面打了一個(gè)字符，那我不僅可以更新文本框里面的內(nèi)容，我還可以更新緩存里面的代碼的內(nèi)容，同時(shí)還可以知道新的緩存開始結(jié)束位置。一個(gè)語句通常都是很短的，最多也就一百來個(gè)字符，因此我們立刻在前臺(tái)對(duì)它做語法分析。而且往一個(gè)語句里面打字的話，99%以上的情況是不會(huì)影響到上下文的，所以這個(gè)語句的舊作用域?qū)ο笕匀豢捎?/strong>。這個(gè)時(shí)候我們用舊的作用域?qū)ο髞韺?duì)新的語句做語義分析，那么就可以知道這個(gè)語句每一個(gè)表達(dá)式的類型了，從而知道了"."前面的表達(dá)式究竟是什么類型。然后利用舊作用域?qū)ο螅覀兙涂梢灾肋@個(gè)類型包含了多少成員。到了這一步，列表里面的對(duì)象就構(gòu)造完畢了。

    然而后臺(tái)的全文分析總是會(huì)結(jié)束的，所有的信息在這個(gè)時(shí)候就準(zhǔn)備好了，然后發(fā)個(gè)消息給前臺(tái)讓它更新緩存。兩種更新緩存都是用GUI的消息驅(qū)動(dòng)的，所以不可能同時(shí)發(fā)生，只會(huì)先后發(fā)生。之前談到的臨時(shí)更新跟后臺(tái)的全文分析是并行的，不過這個(gè)不會(huì)影響我們。只要我們正確處理后臺(tái)跟前臺(tái)的信息交換，那么整個(gè)智能感應(yīng)的計(jì)算過程就可以做得十分安全，不會(huì)發(fā)生死鎖。我相信這一點(diǎn)應(yīng)該不是很難。

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

    在這里我建議大家去閱讀我博客上的兩篇文章，你可以從這兩篇文章所給的鏈接看到一些其他的東西，講的是如何用組合子開發(fā)語法分析器。我這里給語法樹添加了一個(gè)新屬性，也就是一種組合起來強(qiáng)大但是又容易指定的錯(cuò)誤恢復(fù)技術(shù)了。這里的錯(cuò)誤恢復(fù)技術(shù)分為兩種，一種是針對(duì)循環(huán)的，這個(gè)大家看代碼就可以了，因?yàn)楦诙N——也就是序列關(guān)系的文法的錯(cuò)誤恢復(fù)——非常相似，只是一個(gè)理論上的變換而已。

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

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

    至于代碼生成器本身怎么實(shí)現(xiàn)，還是去Vczh Library++ 3.0下載代碼吧。