人們都很喜歡討論閉包這個概念。其實這個概念對於寫程式碼來講一點用都沒有，寫程式碼只需要掌握好lambda表示式和class+interface的語義就行了。基本上只有在寫編譯器和虛擬機器的時候才需要管什麼是閉包。不過因為系列文章主題的緣故，在這裡我就跟大家講一下閉包是什麼東西。在理解閉包之前，我們得先理解一些常見的argument passing和symbol resolving的規則。

首先第一個就是call by value了。這個規則我們大家都很熟悉，因為流行的語言都是這麼做的。大家還記得剛開始學程式設計的時候，書上總是有一道題目，說的是：

void Swap(int a, int
 
 b)
{
    int t = a;
    a = b;
    b = t;
}

int main()
{
    int a=0;
    int b=1;
    Swap(a, b);
    printf("%d, %d", a, b);
}

然後問程式會輸出什麼。當然我們現在都知道，a和b仍然是0和1，沒有受到變化。這就是call by value。如果我們修改一下規則，讓引數總是通過引用傳遞進來，因此Swap會導致main函式最後會輸出1和0的話，那這個就是call by reference了。

除此之外，一個不太常見的例子就是call by need

int Add(int a, int b)
{
    return a + b;
}

int Choose(bool first, int a, int b)
{
    return first ? a : b;
}

int main()
{
    int r = Choose(false, Add(1, 2), Add(3, 4));
    printf(
 
"%d", r);
}

這個程式Add會被呼叫多少次呢？大家都知道是兩次。但是在Haskell裡面這麼寫的話，就只會被呼叫一次。為什麼呢？因為Choose的第一個引數是false，所以函式的返回值只依賴與b，而不依賴與a。所以在main函式裡面它感覺到了這一點，於是只算Add(3, 4)，不算Add(1, 2)。不過大家別以為這是因為編譯器優化的時候內聯了這個函式才這麼幹的，Haskell的這個機制是在執行時起作用的。所以如果我們寫了個快速排序的演算法，然後把一個數組排序後只輸出第一個數字，那麼整個程式是O(n)時間複雜度的。因為快速排序的average case在把第一個元素確定下來的時候，只花了O(n)的時間。再加上整個程式只輸出第一個數字，所以後面的他就不算了，於是整個程式也是O(n)。

於是大家知道call by name、call by reference和call by need了。現在來給大家講一個call by name的神奇的規則。這個規則神奇到，我覺得根本沒辦法駕馭它來寫出一個正確的程式。我來舉個例子：

int Set(int a, int b, int c, int d)
{
    a += b;
    a += c;
    a += d;
}

int main()
{
    int i = 0;
    int x[3] = {1, 2, 3};
    Set(x[i++], 10, 100, 1000);
    printf("%d, %d, %d, %d", x[0], x[1], x[2], i);
}

學過C語言的都知道這個程式其實什麼都沒做。如果把C語言的call by value改成了call by reference的話，那麼x和i的值分別是{1111, 2, 3}和1。但是我們知道，人類的想象力是很豐富的，於是發明了一種叫做call by name的規則。call by name也是call by reference的，但是區別在於你每一次使用一個引數的時候，程式都會把計算這個引數的表示式執行一遍。因此，如果把C語言的call by value換成call by name，那麼上面的程式做的事情實際上就是：

x[i++] += 10;
x[i++] += 100;
x[i++] += 1000;

程式執行完之後x和i的值就是{11, 102, 1003}和3了。

很神奇對吧，稍微不注意就會中招，是個大坑，基本沒法用對吧。那你們還整天用C語言的巨集來代替函式幹什麼呢。我依稀記得Ada（有網友指出這是Algol 60）還是什麼語言就是用這個規則的，印象比較模糊。

講完了argument passing的事情，在理解lambda表示式之前，我們還需要知道兩個流行的symbol resolving的規則。所謂的symbol resolving講的就是解決程式在看到一個名字的時候，如何知道這個名字到底指向的是誰的問題。於是我又可以舉一個簡單粗暴的例子了：

Action<int> SetX()
{
    int x = 0;
    return (int n)=>
    {
        x = n;
    };
}

void Main()
{
    int x = 10;
    var setX = SetX();
    setX(20);
    Console.WriteLine(x);
}

弱智都知道這個程式其實什麼都沒做，就輸出10。這是因為C#用的symbol resolving地方法是lexical scoping。對於SetX裡面那個lambda表示式來講，那個x是SetX的x而不是Main的x，因為lexical scoping的含義就是，在定義的地方向上查詢名字。那為什麼不能在執行的時候向上查詢名字從而讓SetX裡面的lambda表示式實際上訪問的是Main函式裡面的x呢？其實是有人這麼幹的。這種做法叫dynamic scoping。我們知道，著名的javascript語言的eval函式，字串引數裡面的所有名字就是在執行的時候查詢的。

=======================我是背景知識的分割線=======================

想必大家都覺得，如果一個語言的lambda表示式在定義和執行的時候採用的是lexical scoping和call by value那該有多好呀。流行的語言都是這麼做的。就算規定到這麼細，那還是有一個分歧。到底一個lambda表示式抓下來的外面的符號是隻讀的還是可讀寫的呢？python告訴我們，這是隻讀的。C#和javascript告訴我們，這是可讀寫的。C++告訴我們，你們自己來決定每一個符號的規則。作為一個對語言瞭解得很深刻，知道自己每一行程式碼到底在做什麼，而且還很有自制力的程式設計師來說，我還是比較喜歡C#那種做法。因為其實C++就算你把一個值抓了下來，大部分情況下還是不能優化的，那何苦每個變數都要我自己說明我到底是想只讀呢，還是要讀寫都可以呢？函式體我怎麼用這個變數不是已經很清楚的表達出來了嘛。

那說到底閉包是什麼呢？閉包其實就是那個被lambda表示式抓下來的“上下文”加上函式本身了。像上面的SetX函式裡面的lambda表示式的閉包，就是x變數。一個語言有了帶閉包的lambda表示式，意味著什麼呢？我下面給大家展示一小段程式碼。現在要從動態型別的的lambda表示式開始講，就湊合著用那個無聊的javascript吧：

function pair(a, b) {
    return function(c) {
        return c(a, b);
    };
}

function first(a, b) {
    return a;
}

function second(a, b) {
    return b;
}

var p = pair(1, pair(2, 3));
var a = p(first);
var b = p(second)(first);
var c = p(second)(second);
print(a, b, c);

這個程式的a、b和c到底是什麼值呢？當然就算看不懂這個程式的人也可以很快猜出來他們是1、2和3了，因為變數名實在是定義的太清楚了。那麼程式的執行過程到底是怎麼樣的呢？大家可以看到這個程式的任何一個值在建立之後都沒有被第二次賦值過，於是這種程式就是沒有副作用的，那就代表其實在這裡call by value和call by need是沒有區別的。call by need意味著函式的引數的求值順序也是無所謂的。在這種情況下，程式就變得跟數學公式一樣，可以推導了。那我們現在就來推導一下：

var p = pair(1, pair(2, 3));
var a = p(first);

// ↓↓↓↓↓

var p = function(c) {
    return c(1, pair(2, 3));
};
var a = p(first);

// ↓↓↓↓↓

var a = first(1, pair(2, 3));

// ↓↓↓↓↓

var a = 1;

這也算是個老掉牙的例子了啊。閉包在這裡體現了他強大的作用，把引數保留了起來，我們可以在這之後進行訪問。彷彿我們寫的就是下面這樣的程式碼：

var p = {
    first : 1,
    second : {
        first : 1,
        second : 2,
    }
};

var a = p.first;
var b = p.second.first;
var c = p.second.second;

於是我們得到了一個結論，（帶閉包的）lambda表示式可以代替一個成員為只讀的struct了。那麼，成員可以讀寫的struct要怎麼做呢？做法當然跟上面的不一樣。究其原因，就是因為javascript使用了call by value的規則，使得pair裡面的return c(a, b);沒辦法將a和b的引用傳遞給c，這樣就沒有人可以修改a和b的值了。雖然a和b在那些c裡面是改不了的，但是pair函式內部是可以修改的。如果我們要堅持只是用lambda表示式的話，就得要求c把修改後的所有“這個struct的成員變數”都拿出來。於是就有了下面的程式碼：

// 在這裡我們繼續使用上面的pair、first和second函式

function mutable_pair(a, b) {
    return function(c) {
        var x = c(a, b);
        // 這裡我們把pair當連結串列用，一個(1, 2, 3)的連結串列會被儲存為pair(1, pair(2, pair(3, null)))
        a = x(second)(first);
        b = x(second)(second)(first);
        return x(first);
    };
}

function get_first(a, b) {
    return pair(a, pair(a, pair(b, null)));
}

function get_second(a, b) {
    return pair(b, pair(a, pair(b, null)));
}

function set_first(value) {
    return function(a, b) {
        return pair(undefined, pair(value, pair(b, null)));
    };
}

function set_second(value) {
    return function(a, b) {
        return pair(undefined, pair(a, pair(value, null)));
    };
}

var p = mutable_pair(1, 2);
var a = p(get_first);
var b = p(get_second);
print(a, b);
p(set_first(3));
p(set_second(4));
var c = p(get_first);
var d = p(get_second);
print(c, d);

我們可以看到，因為get_first和get_second做了一個只讀的事情，所以返回的連結串列的第二個值（代表新的a）和第三個值（代表新的b）都是舊的a和b。但是set_first和set_second就不一樣了。因此在執行到第二個print的時候，我們可以看到p的兩個值已經被更改成了3和4。

雖然這裡已經涉及到了“繫結過的變數重新賦值”的事情，不過我們還是可以嘗試推導一下，究竟p(set_first(3));的時候究竟幹了什麼事情：

var p = mutable_pair(1, 2);
p(set_first(3));

// ↓↓↓↓↓

p = return function(c) {
    var x = c(1, 2);
    a = x(second)(first);
    b = x(second)(second)(first);
    return x(first);
};
p(set_first(3));

// ↓↓↓↓↓

var x = set_first(3)(1, 2);
p.a = x(second)(first); // 這裡的a和b是p的閉包內包含的上下文的變量了，所以這麼寫會清楚一點
p.b = x(second)(second)(first);
// return x(first);出來的值沒人要，所以省略掉。

// ↓↓↓↓↓

var x = (function(a, b) {
    return pair(undefined, pair(3, pair(b, null)));
})(1, 2);
p.a = x(second)(first);
p.b = x(second)(second)(first);// ↓↓↓↓↓

x = pair(undefined, pair(3, pair(2, null)));
p.a = x(second)(first);
p.b = x(second)(second)(first);// ↓↓↓↓↓

p.a = 3;
p.b = 2;

由於涉及到了上下文的修改，這個推導嚴格上來說已經不能叫推導了，只能叫解說了。不過我們可以發現，僅僅使用可以捕捉可讀寫的上下文的lambda表示式，已經可以實現可讀寫的struct的效果了。而且這個struct的讀寫是通過getter和setter來實現的，於是只要我們寫的複雜一點，我們就得到了一個interface。於是那個mutable_pair，就可以看成是一個建構函式了。

大括號不能換行的程式碼真他媽的難讀啊，遠遠望去就像一坨屎！go語言還把javascript自動補全分號的演算法給抄去了，真是沒品位。

所以，interface其實跟lambda表達是一樣，也可以看成是一個閉包。只是interface的入口比較多，lambda表示式的入口只有一個（類似於C++的operator()）。大家可能會問，class是什麼呢？class當然是interface內部不可告人的實現細節的。我們知道，依賴實現細節來程式設計是不對的，所以我們要依賴介面程式設計。

當然，即使是倉促設計出javascript的那個人，大概也是知道建構函式也是一個函式的，而且類的成員跟函式的上下文連結串列的節點物件其實沒什麼區別。於是我們會看到，javascript裡面是這麼做面向物件的事情的：

function rectangle(a, b) {
    this.width = a;
    this.height = height;
}

rectangle.prototype.get_area = function() {
    return this.width * this.height;
};

var r = new rectangle(3, 4);
print(r.get_area());

然後我們就拿到了一個3×4的長方形的面積12了。不過javascript給我們帶來的一點點小困惑是，函式的this引數其實是dynamic scoping的，也就是說，這個this到底是什麼，要看你在哪如何呼叫這個函式。於是其實

obj.method(args)

整個東西是一個語法，它代表method的this引數是obj，剩下的引數是args。可惜的是，這個語法並不是由“obj.member”和“func(args)”組成的。那麼在上面的例子中，如果我們把程式碼改為：

var x = r.get_area;
print(x());

結果是什麼呢？反正不是12。如果你在C#裡面做這個事情，效果就跟javascript不一樣了。如果我們有下面的程式碼：

class Rectangle
{
    public int width;
    public int height;

    public int GetArea()
    {
        return width * height;
    }
};

那麼下面兩段程式碼的意思是一樣的：

var r = new Rectangle
{
    width = 3;
    height = 4;
};

// 第一段程式碼
Console.WriteLine(r.GetArea());

// 第二段程式碼
Func<int> x = r.GetArea;
Console.WriteLine(x());

究其原因，是因為javascript把obj.method(a, b)解釋成了GetMember(obj, “method”).Invoke(a, b, this = r);了。所以你做r.get_area的時候，你拿到的其實是定義在rectangle.prototype裡面的那個東西。但是C#做的事情不一樣，C#的第二段程式碼其實相當於：

Func<int> x = ()=>
{
    return r.GetArea();
};
Console.WriteLine(x());

所以說C#這個做法比較符合直覺啊，為什麼dynamic scoping（譬如javascript的this引數）和call by name（譬如C語言的巨集）看起來都那麼屌絲，總是讓人掉坑裡，就是因為違反了直覺。不過javascript那麼做還是情有可原的。估計第一次設計這個東西的時候，收到了靜態型別語言太多的影響，於是把obj.method(args)整個當成了一個整體來看。因為在C++裡面，this的確就是一個引數，只是她不能讓你obj.method，得寫&TObj::method，然後還有一個專門填this引數的語法——沒錯，就是.*和->*操作符了。

假如說，javascript的this引數要做成lexical scoping，而不是dynamic scoping，那麼能不能用lambda表示式來模擬interface呢？這當然是可以，只是如果不用prototype的話，那我們就會喪失javascript愛好者們千方百計絞盡腦汁用盡奇技淫巧鎖模擬出來的“繼承”效果了：

function mutable_pair(a, b) {
    _this = {
        get_first = function() { return a; },
        get_second = function() { return b; },
        set_first = function(value) { a = value; },
        set_second = function(value) { b = value; }
    };
    return _this; 
}

var p = new mutable_pair(1, 2);
var a = p.get_first();
var b = p.get_second();
print(a, b);
var c = p.set_first(3);
var d = p.set_second(4);
print(c, d);

這個時候，即使你寫

var x = p.set_first;
var y = p.set_second;
x(3);
y(4);

程式碼也會跟我們所期望的一樣正常工作了。而且創造出來的r，所有的成員變數都遮蔽掉了，只留下了幾個函式給你。與此同時，函式裡面訪問_this也會得到創建出來的那個interface了。

大家到這裡大概已經明白閉包、lambda表示式和interface之間的關係了吧。我看了一下之前寫過的六篇文章，加上今天這篇，內容已經覆蓋了有：

1. 閱讀C語言的複雜的宣告語法
2. 什麼是語法噪音
3. 什麼是語法的一致性
4. C++的const的意思
5. C#的struct和property的問題
6. C++的多重繼承
7. 封裝到底意味著什麼
8. 為什麼exception要比error code寫起來乾淨、容易維護而且不需要太多的溝通
9. 為什麼C#的有些interface應該表達為concept
10. 模板和模板超程式設計
11. 協變和逆變
12. type rich programming
13. OO的訊息傳送的含義
14. 虛擬函式表是如何實現的
15. 什麼是OO裡面的型別擴充套件開放/封閉與邏輯擴充套件開放/封閉
16. visitor模式如何逆轉型別和邏輯的擴充套件和封閉
17. CPS（continuation passing style）變換與非同步呼叫的異常處理的關係
18. CPS如何讓exception變成error code
19. argument passing和symbol resolving
20. 如何用lambda實現mutable struct和immutable struct
21. 如何用lambda實現interface

想了想，大概通俗易懂的可以自學成才的那些東西大概都講完了。當然，系列是不會在這裡就結束的，只是後面的東西，大概就需要大家多一點思考了。

寫程式講究行雲流水。只有自己勤于思考，勤於做實驗，勤於造輪子，才能讓程式設計的學習事半功倍。