像C#或者Haskell這樣的先進的語言都有一個跟語法分不開的最核心的庫。譬如說C#的int，是mscorlib.dll裡面的System.SInt32，Haskell的(x:xs)則定義在了prelude裡面。Vczh Library++ 3.0的ManagedX語言也有一個類似mscorlib.dll的東西。之前的NativeX提供了一個核心的函數庫叫System.CoreNative (syscrnat.assembly)，因此ManagedX的就命名為System.CoreManaged (syscrman.assembly)。System.CoreManaged裡面的預定義對象都是一些基本的、不可缺少的類型，例如System.SInt32、System.IEnumerable<T>或者System.Reflection.Type。昨天晚上我的未完成的語義分析器的完成程度已經足以完全分析System.CoreManaged裡面的托管代碼了，因此符號表裡面的類型系統也基本上是一個完整的類型系統。在開發的過程中得到的心得體會便是寫著一篇文章的來源。
如今，先進的面向對象語言的類型都離不開下面的幾個特征：對象類型、函數類型和接口類型。修飾類型的工具則有泛型和延遲綁定等等。譬如說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表達式，使得我的第一個裡程碑提前到來。
作者“λ-calculus”
