像C#或者Haskell這樣的先進(jìn)的語(yǔ)言都有一個(gè)跟語(yǔ)法分不開(kāi)的最核心的庫(kù)。譬如說(shuō)C#的int，是mscorlib.dll里面的System.SInt32，Haskell的(x:xs)則定義在了prelude里面。Vczh Library++ 3.0的ManagedX語(yǔ)言也有一個(gè)類似mscorlib.dll的東西。之前的NativeX提供了一個(gè)核心的函數(shù)庫(kù)叫System.CoreNative (syscrnat.assembly)，因此ManagedX的就命名為System.CoreManaged (syscrman.assembly)。System.CoreManaged里面的預(yù)定義對(duì)象都是一些基本的、不可缺少的類型，例如System.SInt32、System.IEnumerable<T>或者System.Reflection.Type。昨天晚上我的未完成的語(yǔ)義分析器的完成程度已經(jīng)足以完全分析System.CoreManaged里面的托管代碼了，因此符號(hào)表里面的類型系統(tǒng)也基本上是一個(gè)完整的類型系統(tǒng)。在開(kāi)發(fā)的過(guò)程中得到的心得體會(huì)便是寫著一篇文章的來(lái)源。

 

如今，先進(jìn)的面向?qū)ο笳Z(yǔ)言的類型都離不開(kāi)下面的幾個(gè)特征：對(duì)象類型、函數(shù)類型和接口類型。修飾類型的工具則有泛型和延遲綁定等等。譬如說(shuō)C#，對(duì)象類型便是object，函數(shù)類型則有.net framework支持的很好，但是不是核心類型的Func和Action，接口類型則類似IEnumerable。泛型大家都很熟悉，延遲綁定則類似于dynamic關(guān)鍵字。var關(guān)鍵字是編譯期綁定的，因此不計(jì)算在內(nèi)。Java的int是魔法類型，其設(shè)計(jì)的錯(cuò)誤已經(jīng)嚴(yán)重影響到了類庫(kù)的優(yōu)美程度，其使用“類型擦除”的泛型系統(tǒng)也為今后的發(fā)展留下了一些禍根，因此這些旁門左道本文章就不去詳細(xì)討論了。這篇文章講針對(duì)重要的那三個(gè)類型和兩個(gè)修飾進(jìn)行討論，并解釋他們之間互相換算的方法。

 

在C#里面，函數(shù)類型也是對(duì)象類型的一部分，但是由于C#可以在編譯過(guò)程中把一個(gè)不完整的函數(shù)類型推導(dǎo)為一個(gè)完整的函數(shù)類型，因此在這里將它和對(duì)象類型區(qū)分開(kāi)來(lái)。Haskell則在推導(dǎo)上做得更加徹底，這都是先進(jìn)的有類型語(yǔ)言所不可缺少的一個(gè)特征。由于類型之間的互相換算是本文所關(guān)心的內(nèi)容，因此下面先給出幾個(gè)定義。當(dāng)然這些定義在數(shù)學(xué)上是不嚴(yán)謹(jǐn)?shù)模乙膊⒉蛔非筮@個(gè)。namespace在這里也不是非常重要，因?yàn)榇嬖?/span>namespace和不存在namespace所帶來(lái)的區(qū)別僅僅是一個(gè)對(duì)象被如何解釋（黑話稱之為Resolving），并不影響推導(dǎo)過(guò)程。

 

我們可以將一個(gè)類型命名為T，它是不帶泛型的。一般來(lái)說(shuō)，因?yàn)轭愋痛嬖诔蓡T函數(shù)，所以類型便有幾個(gè)基本的屬性，稱之為this類型和base類型（在C#，代表自己的關(guān)鍵字分別是this和base）。this指的是類型T的成員函數(shù)所看到的自己的類型。而base類型則是父類的類型。在這里有必要做出一點(diǎn)解釋。只有對(duì)象類型才具有base類型，而且其base類型指的是所有父類中唯一一個(gè)不是接口類型的那個(gè)。函數(shù)類型和接口類型都有this類型。

 

因此對(duì)于任何一個(gè)具有下面描述的類型T：

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

this(T) == T

base(T) == U

 

現(xiàn)在讓我們來(lái)考察一個(gè)帶泛型的類型聲明T[U, V]，和他的實(shí)例化類型T<A, B>之間的關(guān)系。我們知道，一個(gè)帶泛型的類型聲明T[U, V]實(shí)際上是一個(gè)不完整的類型，因?yàn)檫@個(gè)類型還有U和V兩個(gè)參數(shù)待填，正如下面的代碼所示：

class T<U, V>{}

而當(dāng)你實(shí)例化他之后，令U==A，V==B，則T類型被A和B實(shí)例化成了T<A, B>。這就有點(diǎn)象我們把一個(gè)Dictionary[K, V]給實(shí)例化成Dictionary<int, string>一樣。一個(gè)實(shí)例化后的類型才可以被當(dāng)成另一個(gè)泛型類型的類型參數(shù)，或者直接使用它來(lái)定義一些符號(hào)，或者創(chuàng)建一個(gè)它的實(shí)例等等。但是不完整的泛型類型T[U, V]和它的實(shí)例化類型T<A, B>都具有共同的屬性——this類型和base類型。按照上面的定義，this類型是該類型的成員函數(shù)所看到的自己的類型。

 

因此對(duì)于任何一個(gè)具有下面描述的類型T[U, V]：

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

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

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

 

當(dāng)然，對(duì)于T<A, B>來(lái)說(shuō)，它也具有this類型T<A, B>和base類型W<A, B>。一般情況下，非泛型類型T的聲明可以被處理成T[]，我們令T[]等于T<>，就可以將所有泛型類型的規(guī)則實(shí)例化到一個(gè)帶有0個(gè)泛型參數(shù)的泛型類型——也就是非泛型類型上面了。因此下面的討論將不作區(qū)分。

 

現(xiàn)在我們考慮如何獲得一個(gè)泛型類型的所有成員的類型。我們考慮下面的一組類型：

 

interface IEnumerable<T>

{

    IEnumerator<T> GetEnumerator();

}

 

class Base<T> : IEnumerable<T>

{

    public T Value{get; set;}

}

 

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

{

}

 

我們來(lái)考慮一個(gè)問(wèn)題：如何知道Derived<int, string>的GetEnumerator函數(shù)的返回值類型是什么呢？乍一看似乎很簡(jiǎn)單，其實(shí)對(duì)于人類來(lái)說(shuō)這個(gè)問(wèn)題的確是僅靠直覺(jué)就可以瞬間回答出來(lái)的、根本沒(méi)有任何障礙的問(wèn)題了。這里我一直佩服大自然可以將人類進(jìn)化到如此牛逼的地步。不過(guò)這個(gè)問(wèn)題困擾了我很久，主要是在開(kāi)發(fā)語(yǔ)義分析器的時(shí)候，安排各種各樣的類型運(yùn)算、符號(hào)表的結(jié)構(gòu)和其它的一些相關(guān)問(wèn)題的時(shí)候，這個(gè)問(wèn)題的難度就提高了。

 

不過(guò)在這里我并不想多說(shuō)什么廢話，我們僅需要給類型對(duì)增加幾個(gè)屬性和運(yùn)算規(guī)則，就可以很容易的將這個(gè)問(wèn)題組合成一個(gè)表達(dá)式了。

 

首先，我們需要有一個(gè)replace操作。replace操作很難一下子嚴(yán)謹(jǐn)?shù)亩x出來(lái)，不過(guò)可以給一個(gè)直觀的定義，就是：

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

相信大家已經(jīng)可以很輕松的理解了，因此對(duì)于一個(gè)類型映射tm={T=>string}來(lái)說(shuō)，replace(Derived<IEnumerable<T>>, tk)的結(jié)果就是Derived<IEnumerable<string>>了。

 

其次，我們需要一個(gè)decl操作，這個(gè)操作返回一個(gè)泛型類型的實(shí)例類型的定義：

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

 

然后，我們還需要一個(gè)params操作。這個(gè)操作將一個(gè)泛型類型的實(shí)例類型和他的泛型定義相比較，提取出可以從泛型定義replace到實(shí)例類型的那個(gè)類型映射：

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

 

因此一般來(lái)說(shuō)，我們有下面的規(guī)則。只要類型T是一個(gè)泛型類型的實(shí)例類型，那么總是有：

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

 

現(xiàn)在我們就可以開(kāi)始回答上面提到的那個(gè)問(wèn)題了。

首先對(duì)于類型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>了

 

其次，我們指定要計(jì)算類型Base<string>所繼承的那個(gè)接口Base[T]=>IEnumerable<T>，我們可以使用

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

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

因此對(duì)于一個(gè)泛型聲明decl(T)所繼承的一個(gè)接口Id，泛型聲明D的實(shí)例類型T所對(duì)應(yīng)的接口It等于replace(Td, params(T))。

 

因此對(duì)于IEnumerable[T]的函數(shù)GetEnumerator的返回值類型IEnumerator<T>，聰明的讀者肯定想到，IEnumerable<string>所對(duì)應(yīng)的類型就是replace(IEnumerator<T>, params(IEnumerable<string>)) == IEnumerator<string>了。這個(gè)結(jié)果跟求實(shí)例類型所繼承的接口類型的方法一樣。

 

我們可以知道，在計(jì)算泛型類型的實(shí)例類型的成員類型中，我們總是不斷地在計(jì)算replace(A, params(B))的結(jié)果。因此在我實(shí)現(xiàn)的帶泛型的面向?qū)ο笸泄苷Z(yǔ)言：Vczh Library++ 3.0的ManagedX語(yǔ)言的語(yǔ)義分析器的符號(hào)表的代碼里面，真實(shí)出現(xiàn)了使用C++所完成的this、base、decl、params、replace和replace_by_type = replace(A, params(B))這樣的六個(gè)函數(shù)。因?yàn)樵?/span>C++里面，一個(gè)類型的實(shí)例只能被表示為一個(gè)帶有復(fù)雜結(jié)構(gòu)的對(duì)象的指針。因此只要符號(hào)表在計(jì)算類型的過(guò)程中，把所有產(chǎn)生出來(lái)的類型保存下來(lái)，建立索引，并且使得“只要類型A和類型B是同一個(gè)類型則有他們的指針P(A)和P(B)相等”的這個(gè)條件恒成立的話，類型系統(tǒng)的計(jì)算速度將直接提高。

 

至于函數(shù)類型的推導(dǎo)法則（主要是應(yīng)用于lambda表達(dá)式的縮寫語(yǔ)法），則等到我開(kāi)發(fā)到那里的時(shí)候再寫后續(xù)的文章了。System.CoreManaged有幸不需要使用lambda表達(dá)式，使得我的第一個(gè)里程碑提前到來(lái)。

    C#真TMD復(fù)雜，讓我好生搞了幾個(gè)月都沒(méi)把一個(gè)山寨C#的語(yǔ)法分析器寫完，就想干脆去搞別的東西好了。因此山寨了個(gè)小WCF還順帶實(shí)踐了一下不需要傳遞password和MD5(password)然后用RSA傳遞AESkey的加密方法，做了一個(gè)client可以new server的類來(lái)做網(wǎng)絡(luò)通訊的東西。完了還搞了搞圖像識(shí)別，不過(guò)最后除了一個(gè)超爛的邊緣檢測(cè)以外也沒(méi)做成什么東西。

    結(jié)果昨天晚上夢(mèng)見(jiàn)我把C#編譯到GPU上面的事情給搞定了（！！！！），然后在夢(mèng)里面就在想：“現(xiàn)在距離javascript編譯到GPU也不遠(yuǎn)了，干脆秒掉他好了。”正要開(kāi)秒，就醒了。

    所以想了想，從今天開(kāi)始，還是繼續(xù)做下去罷。      摘要:     今天看到了校內(nèi)上一個(gè)batman equation，覺(jué)得很順不舒服。第一個(gè)是因?yàn)槲矣X(jué)得那個(gè)圖是錯(cuò)的，第二個(gè)是因?yàn)檫@讓我開(kāi)始思考如何對(duì)任意的f(x, y)進(jìn)行繪制。其實(shí)這是個(gè)很困難的問(wèn)題。但是如果我假設(shè)f(x, y)是處處可微的，那么問(wèn)題說(shuō)不定會(huì)簡(jiǎn)單一點(diǎn)。因此今天晚上就忍不住開(kāi)始寫了。我的想法是，對(duì)于屏幕上的所有點(diǎn)，分別令x或者y等于該點(diǎn)的其中一個(gè)坐標(biāo)元素，對(duì)f...  閱讀全文     自己本來(lái)想體驗(yàn)一下開(kāi)發(fā)一個(gè)簡(jiǎn)陋的模型編輯器以便于把我高中做的那個(gè)破即時(shí)RPG游戲給弄個(gè)續(xù)集的，沒(méi)想到這東西也不是一件好差事啊。先上圖。

    這個(gè)模型編輯器才剛剛開(kāi)始做，菜單都還沒(méi)做完整。暫時(shí)有添加模型、選擇模型、平面或者點(diǎn)、旋轉(zhuǎn)放大平移選中的模型或他的一部分。這樣就花了我兩三個(gè)星期了。DirectX11竟然沒(méi)有D3D11Font，結(jié)果10的Font、D2D10和D3D11Device結(jié)合起來(lái)又十分麻煩，因此我才去了個(gè)猥瑣的做法：創(chuàng)建DIBSections，用GDI畫字，然后逐個(gè)像素變換成D3D11Texture2D需要的格式，最后貼上去。點(diǎn)的高亮矩形也是這么干的。

    然后我創(chuàng)建了一個(gè)sphere，然后拖動(dòng)幾個(gè)選中的點(diǎn)，因此就變成了這樣……

    （代碼可以在Vczh Library++3.0的Candidate\Simulator\DirectX\EditorSolution找到）



     摘要:     Vczh Library++3.0的山寨C#的ManagedX今天完成了一個(gè)功能，就是編譯器檢查一個(gè)類型在他上下文里面是否可用。這個(gè)過(guò)程足夠復(fù)雜，我寫了足足3個(gè)小時(shí)。    ManagedX的符號(hào)表里面的類型已經(jīng)被大大簡(jiǎn)化了。函數(shù)指針是類，基本數(shù)字類型也是類，所以歸根結(jié)底只有    1：子類型&nbs...  閱讀全文      摘要:     DirectX最振奮人心的一點(diǎn)就是，取消了所有固定管線，功能全部用shader來(lái)做。這樣就再也不需要受到各種功能上的限制的束縛了。譬如opengl舊版本的時(shí)候，可以輸入多個(gè)貼圖，然后每一層的貼圖給一個(gè)blend function，搞得好生復(fù)雜。到了后來(lái)，大家都不用固定管線了。現(xiàn)在DirectX11直接取消了固定管線，API反而簡(jiǎn)潔了許多，也不會(huì)有各種鳥(niǎo)事發(fā)生。...  閱讀全文      摘要:     其實(shí)編譯器也不是不做了，只是長(zhǎng)時(shí)間連續(xù)做一個(gè)不能看的編譯器，總是有點(diǎn)不爽。因此我決定把業(yè)余的時(shí)間的主要部分花在編譯器上，而次要的部分則玩游戲，出去游樂(lè)，學(xué)DirectX11。    在我還是14歲的時(shí)候那會(huì)，剛開(kāi)始學(xué)習(xí)編程不久就買了那本《Visual Basic高級(jí)圖形程序設(shè)計(jì)教程》，從此我走上了做圖形的道路上。后來(lái)做游戲，到了大...  閱讀全文      摘要:     由于Vczh Library++3.0的托管語(yǔ)言ManagedX被設(shè)計(jì)成編譯到本地語(yǔ)言NativeX，因此山寨一個(gè)mscorlib.dll是必不可少的。不過(guò)我的mscorlib.dll只包含最低限度的代碼。譬如說(shuō)string，譬如說(shuō)數(shù)組，譬如說(shuō)函數(shù)類型等等這些本不能用托管語(yǔ)言自己來(lái)實(shí)現(xiàn)的類（C++是唯一的一個(gè)所有東西都可以用類庫(kù)來(lái)彌補(bǔ)的語(yǔ)言）。因此花費(fèi)了數(shù)日，...  閱讀全文