類(lèi)型推導(dǎo)到這里也就結(jié)束了。雖然可能有點(diǎn)小bug，不過(guò)這個(gè)以后遇到再處理了。接下來(lái)的一個(gè)模塊是跟類(lèi)型推導(dǎo)沒(méi)有耦合的新模塊，兩邊可以平行處理。

    Kernel FP的指令集不同于以往的指令集。因?yàn)樽鳛橐婚T(mén)純函數(shù)式語(yǔ)言，就必須要有l(wèi)aziness。這就是說(shuō)，凡是可以不運(yùn)行的代碼都一定不運(yùn)行，凡是可以晚一點(diǎn)執(zhí)行的代碼一律等到需要的時(shí)候再執(zhí)行。也就是說(shuō)，參數(shù)傳進(jìn)函數(shù)的時(shí)候，傳的是代碼而不是值。我們可以得到一個(gè)推論就是：代碼的執(zhí)行順序是不能影響程序的執(zhí)行結(jié)果的，如果兩個(gè)表達(dá)式耦合了，那么一定是確定了順序的。因此指令集只能用來(lái)表達(dá)代碼的邏輯結(jié)構(gòu)。

    其實(shí)確定順序是一個(gè)什么樣子的東西呢？舉個(gè)例子，我們擁有一個(gè)從用戶(hù)那里讀字符串的函數(shù)：Input，我們需要將用戶(hù)輸入的三個(gè)字符串傳入一個(gè)函數(shù)：
    Function Input Input Input
    實(shí)際上這是不行的，因?yàn)槿齻€(gè)Input是耦合的，因此他們必須滿(mǎn)足嵌套關(guān)系。當(dāng)然，編譯器會(huì)檢查出來(lái)。

    實(shí)際上怎么寫(xiě)呢？因?yàn)轫樞蛞_定，所以邏輯上大概就是：
    do
        a=Input
        b=Input
        c=Input
        pack (Function a b c)
    end

    Kernel FP沒(méi)有變量，因此abc只是三個(gè)表達(dá)式的別名而已。那么我們?nèi)绾螌⒋a轉(zhuǎn)變?yōu)榍短椎谋磉_(dá)式以便推導(dǎo)呢：我們可以產(chǎn)生若干臨時(shí)函數(shù)：
    我們用\a->b來(lái)表達(dá)一個(gè)匿名函數(shù)，輸入a返回b
    Input >>= \a->( Input >>= \b-> (Input >>= \c-> (pack (Function a b c))))
    當(dāng)然，根據(jù)優(yōu)先級(jí)我們可以去掉一些括號(hào)：
    Input >>= \a->Input >>= \b->Input >>= \c-> pack (Function a b c)

    這個(gè)時(shí)候仍然不能保證三個(gè)Input的執(zhí)行順序，因此我們將Input定義為一個(gè)需要一個(gè)狀態(tài)參數(shù)的函數(shù)，然后定義>>=去傳遞狀態(tài)。剩下來(lái)就是大家都無(wú)比熟悉的Monad了，略過(guò)不講。因?yàn)楫a(chǎn)生狀態(tài)只能由Input這個(gè)黑盒自己搞，所以由于類(lèi)型系統(tǒng)的約束，第三個(gè)Input需要的狀態(tài)參數(shù)由第二個(gè)Input產(chǎn)生，遞歸下去，順序就被強(qiáng)制確定了。

    當(dāng)然，未來(lái)的語(yǔ)法應(yīng)該會(huì)很漂亮的。

    Kernel FP的laziness是通過(guò)對(duì)代碼的推導(dǎo)自動(dòng)獲得的。這個(gè)推導(dǎo)跟我們?cè)谧鰯?shù)學(xué)題的推導(dǎo)是一樣的。我們看一個(gè)例子：

    sum count xs求數(shù)組前count項(xiàng)合，array i則產(chǎn)生[i , i+1 , i+2...]這樣的無(wú)窮數(shù)組，因此main的結(jié)構(gòu)必然是1+2+3=6。推導(dǎo)過(guò)程如下：

    接下來(lái)要做的是，確定指令集的形式了。指令集的作用有兩個(gè)，產(chǎn)生代碼以及推導(dǎo)代碼。