可擴展編譯器架構的構想是最近幾天在洗澡的時候才最終完成的。我在思考如何開發一個可以同時給C、Pascal、Basic、Fortran和未知的類似語言使用的前端+后端。這只是VL++3.0的其中一個小部分，我把語言歸為幾類，C一類，C#一類，Javascript一類，還有其他的等等。這些類型會分別提供不同的前端支持。在設計第一類的編譯器期間遇到了點困難。

    第一個困難是語法樹很難統一。其實這并不是說那些語言完全不同，而是在于我想讓這N種語言的區別只有從字符串到語法樹的部分，從語法樹開始都執行相同的代碼來編譯。這就遇到了點麻煩。在語法分析的過程中，對于Pascal我不知道Name(Param)究竟是函數調用還是強制類型轉換，對于Basic來說我不知道Name(Param)是函數調用還是數組下標。還有Pascal和Basic的and等操作符可以同時作用于整數和布爾型（C使用了&&和&，而且它們在實現上有巨大差別）。Pascal自己還擴展了一些類型譬如說set，Pascal和Basic還有字符串。所以在語法分析的時候很難構直接造出FunctionInvokeExpression、SubscribeExpression和TypeCastExpression。

    第二個困難是擴展的類型。上面提到了Pascal有自己的set，我如何讓我的編譯器從前端開始就可以應付一門類似的未知語言他自己的新東西。譬如說未知的set類型，他也有自己的操作符（連已經存在的操作符operator+也可以用的），代碼生成的時候還有自己的方法。這不僅要求語法樹是可擴展的，接下來的一切包括符號表、語義分析、代碼生成等所有部分都需要可擴展的。

    第三個困難是C自己造成的，他有一個十分討厭的地方。當我得到ABC*DEF;的時候，語義分析沒開始，我不可能知道這是乘法還是定義一個變量。

    思考了許久，得出一個大概的方案：我先定義一門比較嚴格的語言，然后讓C、Pascal、Basic和Fortran來定義自己與該語言的不同之處，從而盡可能復用編譯器其余相同的部分。想到這里我得到一個比較奇怪的做法：

    第一個做法是在語義分析的時候修改語法樹。對于C語言的ABC*DEF;，這是一個statement。我給出一個接口，這個接口在語義分析的過程中被調用。語義分析產生了大量的信息全部傳遞過去，然后再第一次接觸到一個statement的時候，調用其中的ReplaceStatement函數。這個時候接口的ReplaceStatement可以通過語義分析的結果看看需不需要修改這個節點。如果上下文是int a,b;，那么a*b;就會被替換為乘法表達式。如果上下文是typedef int a;，那么a*b;保持不變（因為我默認是優先看成變量聲明）。ReplaceStatement對于同一個statement只會調用一次。至于Pascal的集合操作也可以通過這個來完成。對于a+b，可以在ReplaceExpression里面查看a和b是不是集合類型，如果是的話替換成自己的PascalSetBinaryExpression。這個小技巧解決了語法分析的時候遇到的歧義問題。這也是沒有辦法的辦法，因為這一次設計出來的結構的目的是為了讓新的語言可以用很小的代價來實現。

    第二個做法是語法樹的所有部分譬如Type、Expression、Statement和Declaration都存在一個ExtendedType、ExtendedExpression、ExtendedStatement和ExtendedDeclaration，語言可以通過繼承這四個“擴展類”來提供未知的東西，當然這個時候就要連帶提供所有操作了，譬如說根據語義分析的上下文來判斷他自己的ExtendedExpression的返回類型啦。

    至于符號表的可擴展性，我設計了一個可以應付絕大多數情況的通用符號表，因此隨時加入新的東西還是比較容易的。

    最新的代碼可以在http://vlpp.codeplex.com/這里獲得。