跟vczh看例項學編譯原理——一：Tinymoe的設計哲學

自從《序》胡扯了快一個月之後，終於迎來了正片。之所以系列文章叫《看例項學編譯原理》，是因為整個系列會通過帶大家一步一步實現Tinymoe的過程，來介紹編譯原理的一些知識點。

 

但是第一個系列還沒到開始處理Tinymoe原始碼的時候，首先的跟大家講一講我設計Tinymoe的故事。為什麼這種東西要等到現在才講呢，因為之前沒有文件，將了也是白講啊。Tinymoe在github的wiki分為兩部分，一部分是介紹語法的，另一部分是介紹一個最小的標準庫是如何實現出來的，地址在 https://github.com/vczh/tinymoe/wiki 不帶問號的那些都是寫完了的。

系列文章的目標

在介紹Tinymoe之前，先說一下這個系列文章的目標。Ideally，只要一個人看完了這個系列，他就可以在下面這些地方得到入門：

• 詞法分析
• 歧義與不歧義的語法分析
• 語義分析
• 符號表
• 全文CPS變換
• 編譯生成高效的其他語言的程式碼
• 編譯生成自己的指令集
• 帶GC的虛擬機器
• 型別推導（intersection type，union type，concept mapping）
• 跨過程分析（inter-procedural analyzing）

 

當然，這並不能讓你成為一個大牛，但是至少自己做做實驗，搞一點高大上的東西騙師妹們是沒有問題了。

Tinymoe設計的目標

雖然想法很多年前就已經有了，但是這次我想把它實現出來，是為了完成《如何設計一門語言》的後續。光講大道理是沒有意義的，至少得有一個例子，讓大家知道這些事情到底是什麼樣子的。因此Tinymoe有一點教學的意義，不管是使用它還是實現它。

 

首先，處理Tinymoe需要的知識點多，用於編譯原理教學。既然是為了展示編譯原理的基礎知識，因此語言本身不可能是那種爛大街的C系列的東西。當然除了知識點以外，還會讓大家深刻的理解到，難實現和難用，是完全沒有關係的！Tinymoe用起來可爽了，啊哈哈哈哈哈。

 

其次，Tinymoe容易嵌入其他語言的程式，作為DSL使用，可以呼叫宿主程式提供的功能。這嚴格的來講不算語言本身的功能，而是實現本身的功能。就算是C++也可以設計為嵌入式，lua也可以被設計為編譯成exe的。一個語言本身的設計並不會對如何使用它有多大的限制。為了讓大家看了這個系列之後，可以寫出至少可用的東西，而不僅僅是寫玩具，因此這也是設計的目標之一。

 

第三，Tinymoe語法優化於描述複雜的邏輯，而不是優化與複雜的資料結構和演算法（雖然也可以）。Tinymoe本身是不存在任何細粒度控制記憶體的能力的，而且雖然可以實現複雜的資料結構和演算法，但是本身描述這些東西最多也就跟JavaScript一樣容易——其實就是不容易。但是Tinymoe設計的時候，是為了讓大家把Tinymoe當成是一門可以設計DSL的語言，因此對複雜邏輯的描述能力特別強。唯一的前提就是，你懂得如何給Tinymoe寫庫。很好的使用和很好地實現一個東西是相輔相成的。我在設計Tinymoe之初，很多pattern我也不知道，只是因為設計Tinymoe遵循了科學的方法，因此最後我發現Tinymoe竟然具有如此強大的描述能力。當然對於讀者們本身，也會在閱讀系列文章的有類似的感覺。

 

最後，Tinymoe是一個動態型別語言。這純粹是我的個人愛好了。對一門動態型別語言做靜態分析那該多有趣啊，啊哈哈哈哈哈哈。

Tinymoe的設計哲學

當然我並不會為了寫文章就無線提高Tinymoe的實現難度的。為了把他控制在一個正常水平，因此設計Tinymoe的第一條就是：

 

一、小規模的語言核心+大規模的標準庫

 

其實這跟C++差不多。但是C++由於想做的事情實在是太多了，譬如說檢視包涵所有正規化等等，因此就算這麼做，仍然讓C++本身包含的東西過於巨大（其實我還是覺得C++不難怎麼辦）。

 

語言核心小，實現起來當然容易。但是你並不能為了讓語言核心小就犧牲什麼功能。因此精心設計一個核心是必須的，因為所有你想要但是不想加入語言的功能，從此就可以用庫來實現了。

 

譬如說，Tinymoe通過有條件地暴露continuation，要求編譯器在編譯Tinymoe的時候做一次全文CPS變換。這個東西說容易也不是那麼容易，但是至少比你做分支迴圈異常處理什麼的全部加起來要簡單多了吧。所以我只提供continuation，剩下的控制流全部用庫來做。這樣有三個好處：

1. 語言簡單，實現難度降低。
2. 為了讓庫可以發揮應有的作用，語言的功能的選擇十分的正交化。不過這仍然在一定的程度上提高了學習的難度。但是並不是所有人都需要寫庫對吧，很多人只需要會用庫就夠了。通過一點點的犧牲，正交化可以充分發揮程式設計師的想象能力。這對於以DSL為目的的語言來說是不可或缺的。
3. 標準庫本身可以作為編譯器的測試用例。你只需要準備足夠多的測試用例來執行標準庫，那麼你只要用C++（假設你用C++來實現Tinymoe）來跑他們，那所有的標準庫都會得到執行。執行結果如果對，那你對編譯器的實現也就有信心了。為什麼呢，因為標準庫大量的使用了語言的各種功能，而且是無節操的使用。如果這樣都能過，那普通的程式就更能過了。

 

說了這麼多，那到底什麼是小規模的語言核心呢？這在Tinymoe上有兩點體現。

 

第一點，就是Tinymoe的語法元素少。一個Tinymoe表示式無非就只有三類：函式呼叫、字面量和變數、操作符。字面量就是那些數字字串什麼的。當Tinymoe的函式的某一個引數指定為不定個數的時候你還得提供一個tuple。委託（在這裡是函式指標和閉包的統稱）和陣列雖然也是Tinymoe的原生功能之一，但是對他們的操作都是通過函式呼叫來實現的，沒有特殊的語法。

 

簡單地講，就是除了下面這些東西以外你不會見到別的種類的表示式了：

1

"text"

sum from 1 to 100

sum of (1, 2, 3, 4, 5)

(1+2)*(3+4)

true

 

一個Tinymoe語句的種類就更少了，要麼是一個函式呼叫，要麼是block，要麼是連在一起的幾個block：

do something bad

 

repeat with x from 1 to 100

    do something bad with x

end

 

try

    do something bad

catch exception

    do something worse

end

 

有人可能會說，那repeat和try-catch就不是語法元素嗎？這個真不是，他們是標準庫定義好的函式，跟你自己宣告的函式沒有任何特殊的地方。

 

這裡其實還有一個有意思的地方："repeat with x from 1 to 100"的x其實是迴圈體的引數。Tinymoe是如何給你自定義的block開洞的呢？不僅如此，Tinymoe的函式還可以宣告"引用引數"，也就是說呼叫這個函式的時候你只能把一個變數放進去，函式裡面可以讀寫這個變數。這些都是怎麼實現的呢？學下去就知道了，啊哈哈哈哈。

 

Tinymoe的宣告也只有兩種，第一種是函式，第二種是符號。函式的宣告可能會略微複雜一點，不過除了函式頭以外，其他的都是類似配置一樣的東西，幾乎都是用來定義"catch函式在使用的時候必須是連在try函式後面"啊，"break只能在repeat裡面用"啊，諸如此類的資訊。

 

Tinymoe的符號十分簡單，譬如說你要定義一年四季的符號，只需要這麼寫：

symbol spring

symbol summer

symbol autumn

symbol winter

 

symbol是一個"與眾不同的值"，也就是說你在兩個module下面定義同名的symbol他們也是不一樣的。所有symbol之間都是不一樣的，可以用=和<>來判斷。symbol就是靠"不一樣"來定義其自身的。

 

至於說，那為什麼不用enum呢？因為Tinymoe是動態型別語言，enum的型別本身是根本沒有用武之地的，所以乾脆就設計成了symbol。

 

第二點，Tinymoe除了continuation和select-case以外，沒有其他原生的控制流支援。

 

這基本上歸功於先輩發明continuation passing style transformation的功勞，細節在以後的系列裡面會講。心急的人可以先看 https://github.com/vczh/tinymoe/blob/master/Development/Library/StandardLibrary.txt 。這個檔案暫時包含了Tinymoe的整個標準庫，裡面定義了很多if-else/repeat/try-catch-finally等控制流，甚至連coroutine都可以用continuation、select-case和遞迴來做。

 

這也是小規模的語言核心+大規模的標準庫所要表達的意思。如果可以提供一個feature A，通過他來完成其他必要的feature B0, B1, B2…的同時，將來說不定還有人可以出於自己的需求，開發DSL的時候定義feature C，那麼只有A需要保留下來，所有的B和C都將使用庫的方法來實現。

 

這麼做並不是完全有益無害的，只是壞處很小，在"Tinymoe的實現難點"裡面會詳細說明。

 

二、擴充套件後的東西跟原生的東西外觀一致

 

這是很重要的。如果擴充套件出來的東西跟原生的東西長得不一樣，用起來就覺得很傻逼。Java的string不能用==來判斷內容就是這樣的一個例子。雖然他們有的是理由證明==的反直覺設計是對的——但是反直覺就是反直覺，就是一個大坑。

 

這種例子還有很多，譬如說go的陣列和表的型別啦，go本身如果不要陣列和表的話，是寫不出長得跟原生陣列和表一樣的陣列和表的。其實這也不是一個大問題，問題是go給陣列和表的樣子搞特殊化，還有那個反直覺的slice的賦值問題（會合法溢位！），類似的東西實在是太多了。一個東西特例太多，坑就無法避免。所以其實在我看來，go還不如給C語言加上erlang的actor功能了事。

 

反而C++在這件事情上就做得很好。如果你對C++不熟悉的話，有時候根本分不清什麼是編譯器乾的，什麼是標準庫乾的。譬如說static_cast和dynamic_cast長得像一個模板函式，因此boost就可以用類似的手法加入lexical_cast和針對shared_ptr的static_pointer_cast和dynamic_pointer_cast，整個標準庫和語言本身渾然一體。這樣子做的好處是，當你在培養對語言本身的直覺的時候，你也在培養對標準庫的直覺，培養直覺這件事情你不用做兩次。你對一個東西的直覺越準，學習新東西的速度就越快。所以C++的設計剛好可以讓你在熬過第一個階段的學習之後，後面都覺得無比的輕鬆。

 

不過具體到Tinymoe，因為Tinymoe本身的語法元素太少了，所以這個做法在Tinymoe身上體現得不明顯。

Tinymoe的實現難點

首先，語法分析需要對Tinymoe程式處理三遍。Tinymoe對於語句設計使得對一個Tinymoe程式做語法分析不是那麼直接（雖然比C++什麼的還是容易多了）。舉個例子：

module hello world

 

phrase sum from (lower bound) to (upper bound)

…

end

 

sentence print (message)

…

end

 

phrase main

    print sum from 1 to 100

end

 

第一遍分析是詞法分析，這個時候得把每一個token的行號記住。第二遍分析是不帶歧義的語法分析，目標是把所有的函式頭抽取出來，然後組成一個全域性符號表。第三遍分析就是對函式體裡面的語句做帶歧義的語法分析了。因為Tinymoe允許你定義變數，所以符號表肯定是一邊分析一邊修改的。於是對於"print sum from 1 to 100"這一句，如果你沒有發現"phrase sum from (lower bound) to (upper bound)"和"sentence print (message)"，那根本無從下手。

 

還有另一個例子：

module exception handling

 

…

 

phrase main

    try

        do something bad

    catch

        print "bad thing happened"

    end

end

 

當語法分析做到"try"的時候，因為發現存在try函式的定義，所以Tinymoe知道接下來的"do something bad"屬於呼叫try這個塊函式所需提供的程式碼塊裡面的程式碼。接下來是"catch"，Tinymoe怎麼知道catch是接在try後面，而不是放在try裡面的呢？這仍然是由於catch函式的定義告訴我們的。關於這方面的語法知識可以點選這裡檢視。

 

正因為如此，我們需要首先知道函式的定義，然後才能分析函式體裡面的程式碼。雖然這在一定程度上造成了Tinymoe的語法分析複雜度的提升，但是其複雜度本身並不高。比C++簡單就不說了，就算是C、C#和Java，由於其語法元素太多，導致不需要多次分析所降低的複雜度被完全的抵消，結果跟實現Tinymoe的語法分析器的難度不相上下。

 

其次，CPS變換後的程式碼需要特殊處理，否則直接執行容易導致call stack積累的沒用的東西過多。因為Tinymoe可以自定義操作符，所以操作符跟C++一樣在編譯的時候被轉換成了函式呼叫。每一個函式呼叫都是會被CPS變換的。儘管每一行的函式呼叫次數不多，但是如果你的程式油迴圈，迴圈是通過遞迴來描述（而不是實現，由於CPS變換後Tinymoe做了優化，所以不存在實際上的遞迴）的，如果直接執行CPS變換後的程式碼，算一個1加到1000都會導致stack overflow。可見其call stack裡面堆積的closure數量之巨大。

 

我在做Tinymoe程式碼生成的實驗的時候，為了簡單我在單元測試裡面直接產生了對應的C#程式碼。一開始沒有處理CPS而直接呼叫，程式不僅慢，而且容易stack overflow。但是我們知道（其實你們以後才會知道），CPS變換後的程式碼裡面幾乎所有的call stack項都是浪費的，因此我把整個在生成C#程式碼的時候修改成，如果需要呼叫continuation，就返回呼叫continuation的語句組成的lambda表示式，在最外層用一個迴圈去驅動他直到返回null為止。這樣做了之後，就算Tinymoe的程式碼有遞迴，call stack裡面也不會因為遞迴而積累call stack item了。於是生成的C#程式碼執行飛快，而且無論你怎麼遞迴也永遠不會造成stack overflow了。這個美妙的特性幾乎所有語言都做不到，啊哈哈哈哈哈。

 

當然這也是有代價的，因為本質上我只是把儲存在stack上的context轉移到heap上。不過多虧了.net 4.0的強大的background GC，這樣做絲毫沒有多餘的效能上的損耗。當然這也意味著，一個高效能的Tinymoe虛擬機器，需要一個牛逼的垃圾收集器作為靠山。context產生的closure在函式體真的被執行完之後就會被很快地收集，所以CPS加上這種做法並不會對GC產生額外的壓力，所有的壓力仍然來源於你自己所建立的資料結構。

 

第三，Tinymoe需要動態型別語言的型別推導。當然你不這麼做而把Tinymoe的程式當JavaScript那樣的程式處理也沒有問題。但是我們知道，正是因為V8對JavaScript的程式碼進行了型別推導，才產生了那麼優異的效能。因此這算是一個優化上的措施。

 

最後，Tinymoe還需要跨過程分析和對程式的控制流的化簡（譬如continuation轉狀態機等）。目前具體怎麼做我還在學習當中。不過我們想，既然repeat函式是通過遞迴來描述的，那我們能不能通過對所有程式碼進行inter-procedural analyzing，從而發現諸如

repeat 3 times

    do something good

end

就是一個迴圈，從而生成用真正的迴圈指令（譬如說goto）呢？這個問題是個很有意思的問題，我覺得我如果可以通過學習靜態分析從而解決它，不進我的能力會得到提升，我對你們的科普也會做得更好。

後記

雖然還不到五千字，但是總覺得寫了好多的樣子。總之我希望讀者在看完《零》和《一》之後，對接下來需要學習的東西有一個較為清晰的認識。