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

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

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

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

    第二個(gè)階段就開始了。