文章中引用的程式碼均來自https://github.com/vczh/tinymoe。
實現Tinymoe的第一步自然是一個詞法分析器。詞法分析其所作的事情很簡單，就是把一份程式碼分割成若干個token，記錄下他們所在檔案的位置，以及丟掉不必要的資訊。但是Tinymoe是一個按行分割的語言，自然token列表也就是二維的，第一維是行，第二維是每一行的token。在繼續講詞法分析器之前，先看看Tinymoe包含多少token：
- 符號：(、)、,、:、&、+、-、*、/、\、%、<、>、<=、>=、=、<>
- 關鍵字：module、using、phrase、sentence、block、symbol、type、cps、category、expression、argument、assignable、list、end、and、or、not
- 數字：123、456.789
- 字串："abc\r\ndef"
- 識別符號：tinymoe
- 註釋：-- this is a comment
Tinymoe對於token有一個特殊的規定，就是字串和註釋都是單行的。因此如果一個字串在沒有結束之前就遇到了換行，那麼這種寫法定義為你遇到了一個沒有右雙引號的字串，需要報個錯，然後下一行就不是這個字串的內容了。
一個詞法分析器所需要做的事情，就是把一個字串分解成描述此法的資料結構。既然上面已經說到Tinymoe的token列表是二維的，因此資料結構肯定會體現這個觀點。Tinymoe的詞法分析器程式碼可以在這裡找到：https://github.com/vczh/tinymoe/blob/master/Development/Source/Compiler/TinymoeLexicalAnalyzer.h。
首先是token：
CodeTokenType是一個列舉型別，標記一個token的型別。這個型別比較細化，每一個關鍵字有自己的型別，每一個符號也有自己的型別，剩下的按種類來分。我們可以看到token需要記錄的最關鍵的東西只有三個：型別、內容和程式碼位置。在token記錄程式碼位置是十分重要的，正確地記錄程式碼位置可以讓你能夠報告帶位置的錯誤、從語法樹的節點還原成程式碼位置、甚至在除錯的時候可以把指令也換成位置。
這裡需要提到的是，string_t是一個typedef，具體的宣告可以在這裡看到：https://github.com/vczh/tinymoe/blob/master/Development/Source/TinymoeSTL.h。Tinymoe是完全由標準的C++11和STL寫成的，但是為了適應不同情況的需要，Tinymoe分為依賴code page的版本和Unicode版本。如果編譯Tinymoe程式碼的時候宣告瞭全域性的巨集UNICODE_TINYMOE的話，那Tinymoe所有的字元處理將使用wchar_t，否則使用char。char的型別和Tinymoe編譯器在執行的時候作業系統當前的code page是繫結的。所以這裡會有類似string_t啊、ifstream_t啊、char_t等型別，會在不同的編譯選項的影響下指向不同的STL型別或者原生的C++型別。github上的VC++2013工程使用的是wchar_t的版本，所以string_t就是std::wstring。
Tinymoe的詞法分析器除了token的型別以外，肯定還需要定義整個檔案結構在詞法分析後的結果：
這個資料結構體現了"Tinymoe的token列表是二維的"的這個觀點。一個檔案會被詞法分析器處理成一個shared_ptr<CodeFIle>物件，CodeFile::lines記錄了所有非空的行，CodeLine::tokens記錄了該行的所有token。
現在讓我們來看詞法分析的具體過程。關於如何從正規表示式構造詞法分析器可以在這裡（http://www.cppblog.com/vczh/archive/2008/05/22/50763.html）看到，不過我們今天要講一講如何人肉構造詞法分析器。方法其實是一樣的，首先人肉構造狀態機，然後把用狀態機分析輸入的字串的程式碼抄過來就可以了。但是很少有人會解耦得那麼開，因為這樣寫很容易看不懂，其次有可能會遇到一些極端情況是你無法用純粹的正規表示式來分詞的，譬如說C++的raw string literal：R"tinymoe(這裡的字串沒有轉義)tinymoe"。一個用【R"<一些字元>(】開始的字串只能由【)<同樣的字元>"】來結束，要順利分析這種情況，只能通過在狀態機裡面做hack才能解決。這就是為什麼我們人肉構造詞法分析器的時候，會把狀態和動作都混在一起寫，因為這樣便於處理特殊情況。
不過幸好的是，Tinymoe並沒有這種情況發生。所以我們可以直接從狀態機入手。為了簡單起見，我在下面的狀態機中去掉所有不是+和-的符號。首先，我們需要一個起始狀態和一個結束狀態：
首先我們新增整數和識別符號進去：
其次是加減和浮點：
最後把字串和註釋補全：
這樣狀態機就已經完成了。讀過編譯原理的可能會問，為什麼終結狀態都是由虛線而不是帶有輸入的實現指向的？因為虛線在這裡有特殊的意義，也就是說它不能移動輸入的字串的指標，而且他還要負責新增一個token。當狀態跳到End之後，那他就會變成Start，所以實際上Start和End是同一個狀態。這個狀態機也不是輸入什麼字元都能跳轉到下一個狀態的。所以當你發現輸入的字元讓你無路可走的時候，你就是遇到了一個詞法錯誤。
這樣我們的設計就算完成了，接下來就是如何用C++來實現它了。為了讓程式碼更容易閱讀，我們應該給Start和1-9這麼多狀態起名字，做法如下：
在這裡類似狀態3這樣的狀態被我省略掉了，因為這個狀態唯一的出路就是虛線，所以跳到這個狀態意味著你要立刻執行虛線，也就是說你不需要做"跳到這個狀態"這個動作。因此它不需要有一個名字。
然後你只要按照下面的做法翻譯這個狀態機就可以了：
只要寫到這裡，那麼我們就初步完成了詞法分析器了。其實任何系統的主要功能都是相對容易實現的，往往是次要的功能才需要花費大量的精力來完成，而且還很容易出錯。在這裡"次要的功能"就是——記錄token的行列號，還有維護CodeFile::lines避免空行的出現！
儘管我已經做過了那麼多次詞法分析器，但是我仍然無法一氣呵成寫對，仍然會出一些bug。面對編譯器這種純計算程式，debug的最好方法就是寫單元測試。不過對於不熟悉單元測試的人來講可能很難一下子想到要做什麼測試，在這裡我可以把我給Tinymoe謝的一部分單元測試在這裡貼一下。
第一個，當然是傳說中的"Hello, world!"測試了：
TEST_CASE和TEST_ASSERT（這裡暫時沒有直接用到TEST_ASSERT）是我為了開發Tinymoe隨手擼的一個巨集，可以在Tinymoe的程式碼裡看到。為了檢查我們有沒有粗心大意，我們有必要檢查詞法分析器的任何一個輸出的資料，譬如每一行有多少token，譬如每一個token的行號列好內容和型別。我為了讓這些枯燥的測試用例容易看懂，在這個檔案（https://github.com/vczh/tinymoe/blob/master/Development/TinymoeUnitTest/TestLexicalAnalyzer.cpp）的開頭可以看到FIRST_LINE、FIRST_TOKEN、TOKEN、LAST_TOKEN、NEXT_LINE、LAST_LINE是怎麼定義的。其實吧這些巨集展開，就是一個普通的遍歷CodeFile::lines和CodeLine::tokens的程式，然後TEST_ASSERT一下CodeToken的每一個成員是否我們所需要的值。我相信看到這裡很多人肯定把重點放在巨集和炫技上，而不是如何設計測試用例上，這是有前途的程式設計師和沒前途的程式設計師面對一份資料的反應的重要區別之一。沒前途的程式設計師總是會把注意力放在一些莫名其妙的地方，其中一個例子就是"過早優化"。
第二個測試用例針對的是整數和浮點的輸出和報錯上，重點在於檢查每一個token的列號是不是正確的計算了出來：
第三個測試用例的重點主要是-符號和—註釋的分析：
第四個測試用例則是測試字串的escaping和在面對換行的時候是否正確的處理（之前提到字串不能換行，遇到一個突然的換行將會被看成缺少雙引號）：
鑑於詞法分析本來內容也不多，所以這篇文章也不會太長。相信有前途的程式設計師也會在這裡得到一些編譯原理以外的知識。下一篇文章將會描述Tinymoe的函式頭的語法分析部分，將會描述一個編譯器的不帶歧義的語法分析是如何人肉出來的。敬請期待。