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

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

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

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

    第二個階段就開始了。