我至今依稀还记得毕业前做Vczh Library++3.0的伟大目标，就是实现把动态语言通过“动态语言”->“托管语言”->“本地语言”->“低级中间指令”->“X86代码”最终编译成机器码，同时开放出所有中间过程。这样的话添加一个就变成一个写parser的简单工作，添加一个类库会惠及所有语言，添加一个运行是目标（譬如说可以输出ARM等）可以让在这上面的所有语言都能运行在该目标是。现在第一个阶段完成了，就是把本地语言和低级中间指令给做了。

    其实现在叫本地语言不太合适，只是那个东西就是C+泛型+concept mapping的组合体，可以轻易被翻译成X86，所以才这么叫的。暂时还是写了个虚拟机直接执行低级中间指令。在整个开发过程中，我还给这种语言写了一个基本的函数库：字符串、数学函数、内存管理、垃圾收集（只是函数库，而不是语法，目前只有简单的暂时的实现）、线程、同步原语和线程池。有了这些设施之后就可以开始做托管语言了。

    托管语言比较麻烦的地方在于类库是必需的。譬如说字符串、数组和函数对象这些东西其实是无法靠语言本身做出来的，所以只能成为预定义的类库。那这些类库用什么写呢？当然是我们的本地语言（之前还写了一个叫NativeX的parser）啦。现在的设想就有，先把预定义的类库的声明用托管语言本身写出来，然后编译器会提供一个功能将托管语言编译成本地语言（目标箭头之一），然后把所有标记成“外部函数”的函数跳过。每一个函数在生成本地语言的时候都会给出一个经过计算的名字。然后只需要再用NativeX写出这些同名的函数实现就好了。剩下的一些能够用托管语言自己实现的函数，就可以整个被编译成本地语言。编译出来的本地语言会依赖与之前写出来的一个垃圾收集函数库。这种函数库在本地语言只有一个声明，脚本引擎在运行的时候可以给这些名字bind上一个实现。所以实际上垃圾收集函数库的实现是可以替换的（只是必须在初始化的时候指定）。将来万一我重写的实现不够好，人们还能自己搞一套出来换掉，达到他们不可告人的目的。

    至于托管语言本身有什么功能，肯定是抄自这个世界上最先进的弱类型以面向对象作为主要范式的托管语言——C#啦，啊哈哈哈哈。Java的语言本身根本没有被抄的价值。至于之后的动态语言，肯定是被编译到托管语言的。只是这个过程不会跟DLR那么简单直接把类型和表达式拿去映射。这里面可以做很多有趣的事情的，譬如尽量推导出动态语言里面每一个变量的类型约束（我们很多时候其实都知道动态语言里面的某个变量是有限若干个类型的集合的），然后为他们产生出更加有效的代码。这里可能会将一个函数编译成目的相同但是类型不同的几份（注意这里不是在做泛型展开）。

    第二个阶段就开始了。