如今，先进的面向对象语言的类型都离不开下面的几个特征：对象类型、函数类型和接口类型。修饰类型的工具则有泛型和延迟绑定等等。譬如说C#，对象类型便是object，函数类型则有.net framework支持的很好，但是不是核心类型的Func和Action，接口类型则类似IEnumerable。泛型大家都很熟悉，延迟绑定则类似于dynamic关键字。var关键字是编译期绑定的，因此不计算在内。Java的int是魔法类型，其设计的错误已经严重影响到了类库的优美程度，其使用“类型擦除”的泛型系统也为今后的发展留下了一些祸根，因此这些旁门左道本文章就不去详细讨论了。这篇文章讲针对重要的那三个类型和两个修饰进行讨论，并解释他们之间互相换算的方法。

在C#里面，函数类型也是对象类型的一部分，但是由于C#可以在编译过程中把一个不完整的函数类型推导为一个完整的函数类型，因此在这里将它和对象类型区分开来。Haskell则在推导上做得更加彻底，这都是先进的有类型语言所不可缺少的一个特征。由于类型之间的互相换算是本文所关心的内容，因此下面先给出几个定义。当然这些定义在数学上是不严谨的，而我也并不追求这个。namespace在这里也不是非常重要，因为存在namespace和不存在namespace所带来的区别仅仅是一个对象被如何解释（黑话称之为Resolving），并不影响推导过程。

我们可以将一个类型命名为T，它是不带泛型的。一般来说，因为类型存在成员函数，所以类型便有几个基本的属性，称之为this类型和base类型（在C#，代表自己的关键字分别是this和base）。this指的是类型T的成员函数所看到的自己的类型。而base类型则是父类的类型。在这里有必要做出一点解释。只有对象类型才具有base类型，而且其base类型指的是所有父类中唯一一个不是接口类型的那个。函数类型和接口类型都有this类型。

因此对于任何一个具有下面描述的类型T：

class T : U, I1, I2, I3{}

this(T) == T

base(T) == U

现在让我们来考察一个带泛型的类型声明T[U, V]，和他的实例化类型T<A, B>之间的关系。我们知道，一个带泛型的类型声明T[U, V]实际上是一个不完整的类型，因为这个类型还有U和V两个参数待填，正如下面的代码所示：

class T<U, V>{}

而当你实例化他之后，令U==A，V==B，则T类型被A和B实例化成了T<A, B>。这就有点象我们把一个Dictionary[K, V]给实例化成Dictionary<int, string>一样。一个实例化后的类型才可以被当成另一个泛型类型的类型参数，或者直接使用它来定义一些符号，或者创建一个它的实例等等。但是不完整的泛型类型T[U, V]和它的实例化类型T<A, B>都具有共同的属性——this类型和base类型。按照上面的定义，this类型是该类型的成员函数所看到的自己的类型。

因此对于任何一个具有下面描述的类型T[U, V]：

class T<U, V> : W<U, V>{}

this(T[U, V]) == T<U, V>

base(T[U, V]) == W<U, V>

当然，对于T<A, B>来说，它也具有this类型T<A, B>和base类型W<A, B>。一般情况下，非泛型类型T的声明可以被处理成T[]，我们令T[]等于T<>，就可以将所有泛型类型的规则实例化到一个带有0个泛型参数的泛型类型——也就是非泛型类型上面了。因此下面的讨论将不作区分。

现在我们考虑如何获得一个泛型类型的所有成员的类型。我们考虑下面的一组类型：

interface IEnumerable<T>

{

    IEnumerator<T> GetEnumerator();

}

class Base<T> : IEnumerable<T>

{

    public T Value{get; set;}

}

class Derived<T, U> : Base<U>

{

}

我们来考虑一个问题：如何知道Derived<int, string>的GetEnumerator函数的返回值类型是什么呢？乍一看似乎很简单，其实对于人类来说这个问题的确是仅靠直觉就可以瞬间回答出来的、根本没有任何障碍的问题了。这里我一直佩服大自然可以将人类进化到如此牛逼的地步。不过这个问题困扰了我很久，主要是在开发语义分析器的时候，安排各种各样的类型运算、符号表的结构和其它的一些相关问题的时候，这个问题的难度就提高了。

不过在这里我并不想多说什么废话，我们仅需要给类型对增加几个属性和运算规则，就可以很容易的将这个问题组合成一个表达式了。

首先，我们需要有一个replace操作。replace操作很难一下子严谨的定义出来，不过可以给一个直观的定义，就是：

replace(Derived<T, U>, {T=>int, U=>string}) == Derived<int, string>

相信大家已经可以很轻松的理解了，因此对于一个类型映射tm={T=>string}来说，replace(Derived<IEnumerable<T>>, tk)的结果就是Derived<IEnumerable<string>>了。

其次，我们需要一个decl操作，这个操作返回一个泛型类型的实例类型的定义：

decl(T<A, B>) == T[U, V]

然后，我们还需要一个params操作。这个操作将一个泛型类型的实例类型和他的泛型定义相比较，提取出可以从泛型定义replace到实例类型的那个类型映射：

params(T<A, B>) == {T=>A, U=>B}

因此一般来说，我们有下面的规则。只要类型T是一个泛型类型的实例类型，那么总是有：

replace(this(decl(T)), params(T)) == T

现在我们就可以开始回答上面提到的那个问题了。

首先对于类型Derived<int, string>，我们需要找到他的父类。因此我们可以做如下几步操作：

tm = params(Derived<int, string>) = {T=>int, U=>string}

tb = base(decl(Derived<int, string>)) = base(Derived[T, U]) = Base<U>

result = replace(tb, tm) = replace(Base<U>, {T=>int, U=>string}) = Base<string>

这样我们就成功求出T=Derived<int, string>的父类B=replace(base(decl(T)), params(T))=Base<string>了

其次，我们指定要计算类型Base<string>所继承的那个接口Base[T]=>IEnumerable<T>，我们可以使用

tm = params(Base<string>) = {T=>string}

result = replace(IEnumerable<T>, tm) = IEnumerable<string>

因此对于一个泛型声明decl(T)所继承的一个接口Id，泛型声明D的实例类型T所对应的接口It等于replace(Td, params(T))。

因此对于IEnumerable[T]的函数GetEnumerator的返回值类型IEnumerator<T>，聪明的读者肯定想到，IEnumerable<string>所对应的类型就是replace(IEnumerator<T>, params(IEnumerable<string>)) == IEnumerator<string>了。这个结果跟求实例类型所继承的接口类型的方法一样。

我们可以知道，在计算泛型类型的实例类型的成员类型中，我们总是不断地在计算replace(A, params(B))的结果。因此在我实现的带泛型的面向对象托管语言：Vczh Library++ 3.0的ManagedX语言的语义分析器的符号表的代码里面，真实出现了使用C++所完成的this、base、decl、params、replace和replace_by_type = replace(A, params(B))这样的六个函数。因为在C++里面，一个类型的实例只能被表示为一个带有复杂结构的对象的指针。因此只要符号表在计算类型的过程中，把所有产生出来的类型保存下来，建立索引，并且使得“只要类型A和类型B是同一个类型则有他们的指针P(A)和P(B)相等”的这个条件恒成立的话，类型系统的计算速度将直接提高。

至于函数类型的推导法则（主要是应用于lambda表达式的缩写语法），则等到我开发到那里的时候再写后续的文章了。System.CoreManaged有幸不需要使用lambda表达式，使得我的第一个里程碑提前到来。

    这次为了完成一个多编程语言+多自然语言的文档编写工具，不得不做一个可以一次生成一大批文本文件的模板结构出来。有了模板必然有元数据，元数据必然是类似字符串的东西，所以顺手就支持了xml和json。为了应付巨大的xml和json，必然要做出xml和json的流式读写。大家应该听说过SAX吧，大概就是那样的。

    有了xml和json之后，就可以在上面实现query了。把xml和json统一起来是一个比较麻烦的问题，因为本身从结构上来看他们是不相容的。而且为了便于给vlscript.dll添加compiler service的支持，势必要在dll上面做出字符串到语法树或者语法树到字符串这样子的操作。本地dll接口显然不可能做出一个顺眼的异构树结构，因此势必要把语法树表示成xml或者json。因此就有了下面的结构：

    1、一颗简洁但是功能强大的字符串，在上面可以存放xml、json和强类型数据。
    2、可以把xml和树相互转换。
    3、可以把json和树相互转换。
    4、当树存放的是强类型数据（基本类型都会用字符串存放）的时候，树可以映射到一个带有约束的xml或者json结构上去。

    在这里可以展示一下什么是强类型数据。我们知道json表达的结构是弱类型的。当你拿到一个object的时候你不知道它的类型，你只知道他有多少个成员变量。强类型结构要求object有一个类型标记，数组也有一个类型标记（因为我们不能从数组的元素类型推断出数组本身的类型——因为类型可以拥有继承关系），基本类型还要可扩展（json只支持数字、字符串、布尔值和null，显然是不够的）。下面贴一个强类型数据结构的xml和json的表现形式：

    这段简单的加法代码没什么好解释的。窥孔优化还没做，因此会有一些垃圾在里面。在这里可以看到全局变量的访问跟参数访问的不同。全局变量使用link_pushdata，而参数使用stack_offset。link_开头的都是链接时指令，链接器会把这些东西给转换成真正的指令。因为在编译的时候并不知道全局空间的实际指针，因此只好链接的时候再做，这个时候全局空间已经生成出来了。最终link_pushdata会被转换成一个push ptr x指令，x是一个常数。

    下面是调用这个Assembly里面的另一个Assembly的main函数：