我至今依稀還記得畢業(yè)前做Vczh Library++3.0的偉大目標，就是實現(xiàn)把動態(tài)語言通過“動態(tài)語言”->“托管語言”->“本地語言”->“低級中間指令”->“X86代碼”最終編譯成機器碼，同時開放出所有中間過程。這樣的話添加一個就變成一個寫parser的簡單工作，添加一個類庫會惠及所有語言，添加一個運行是目標（譬如說可以輸出ARM等）可以讓在這上面的所有語言都能運行在該目標是。現(xiàn)在第一個階段完成了，就是把本地語言和低級中間指令給做了。

    其實現(xiàn)在叫本地語言不太合適，只是那個東西就是C+泛型+concept mapping的組合體，可以輕易被翻譯成X86，所以才這么叫的。暫時還是寫了個虛擬機直接執(zhí)行低級中間指令。在整個開發(fā)過程中，我還給這種語言寫了一個基本的函數(shù)庫：字符串、數(shù)學(xué)函數(shù)、內(nèi)存管理、垃圾收集（只是函數(shù)庫，而不是語法，目前只有簡單的暫時的實現(xiàn)）、線程、同步原語和線程池。有了這些設(shè)施之后就可以開始做托管語言了。

    托管語言比較麻煩的地方在于類庫是必需的。譬如說字符串、數(shù)組和函數(shù)對象這些東西其實是無法靠語言本身做出來的，所以只能成為預(yù)定義的類庫。那這些類庫用什么寫呢？當然是我們的本地語言（之前還寫了一個叫NativeX的parser）啦。現(xiàn)在的設(shè)想就有，先把預(yù)定義的類庫的聲明用托管語言本身寫出來，然后編譯器會提供一個功能將托管語言編譯成本地語言（目標箭頭之一），然后把所有標記成“外部函數(shù)”的函數(shù)跳過。每一個函數(shù)在生成本地語言的時候都會給出一個經(jīng)過計算的名字。然后只需要再用NativeX寫出這些同名的函數(shù)實現(xiàn)就好了。剩下的一些能夠用托管語言自己實現(xiàn)的函數(shù)，就可以整個被編譯成本地語言。編譯出來的本地語言會依賴與之前寫出來的一個垃圾收集函數(shù)庫。這種函數(shù)庫在本地語言只有一個聲明，腳本引擎在運行的時候可以給這些名字bind上一個實現(xiàn)。所以實際上垃圾收集函數(shù)庫的實現(xiàn)是可以替換的（只是必須在初始化的時候指定）。將來萬一我重寫的實現(xiàn)不夠好，人們還能自己搞一套出來換掉，達到他們不可告人的目的。

    至于托管語言本身有什么功能，肯定是抄自這個世界上最先進的弱類型以面向?qū)ο笞鳛橹饕妒降耐泄苷Z言——C#啦，啊哈哈哈哈。Java的語言本身根本沒有被抄的價值。至于之后的動態(tài)語言，肯定是被編譯到托管語言的。只是這個過程不會跟DLR那么簡單直接把類型和表達式拿去映射。這里面可以做很多有趣的事情的，譬如盡量推導(dǎo)出動態(tài)語言里面每一個變量的類型約束（我們很多時候其實都知道動態(tài)語言里面的某個變量是有限若干個類型的集合的），然后為他們產(chǎn)生出更加有效的代碼。這里可能會將一個函數(shù)編譯成目的相同但是類型不同的幾份（注意這里不是在做泛型展開）。

    第二個階段就開始了。