序言

我的畢設是做一個編譯器型別的音樂遊戲，基於SSM架構。由於前端製作水平和美術功底的限制，我只能靠著別人的網頁模版來製作。
現在前端大致已經制作的差不多，後端框架和環境已經搭好。萬事俱備，只欠東風——核心演算法。
關於核心演算法，之前也想了很多，但是萬事都要踏踏實實的來做，所以我打算從本篇序言開始整理自己的思路。
首先編譯器型別的遊戲，並不真正意味著要製作一個編譯器，也許只需要文法、語法、語義識別，可能之後會用到java反射進行連結（通過使用者的輸入，我進行翻譯，寫為java然後或許能通過反射執行以及呼叫前端）。說不定思考到後期，寫一個新的語言出來（支援中文也說不定啊）。
這個序言也是為了以後的論文做的準備，俗話說得好：

萬事開頭難，然後中間難，最後結尾難。

嗯，編譯原理課程以前也接觸過，也自己寫過文法、語法檢查。不過完整的一套流程並沒有走過，也需要好好探索。

編譯器的模組化工程

為什麼要將編譯器生成一個個階段、一個個模組呢？原因是更加容易設計和減少冗餘。正如OSI七層模型，多麼精美的架構啊。而編譯器的模組劃分的越清晰，工作就越簡單。譬如，詞法分析階段將輸入的字元流轉為token流，就大大減少了語法分析階段需要判斷的輸入種類，在簡化設計的同時還可以提高效能。此外模組化還將編譯器各個階段的工作儘量獨立展開，而不會重新設計系統。

編譯器的階段：

• 詞法分析–>產生token，可用於語法高亮。
• 語法分析–>產生抽象語法樹，可用於語法高亮、程式碼格式化、程式碼摺疊。
• 語義分析–>產生帶型別資訊和符號表的抽象語法樹，可用於重新命名、重構、程式碼自動生成、程式碼自動改寫。
• 資料流分析–>產生控制流圖、衝突圖，可用於編輯後繼續執行（Edit and Continue）。

用途當然不止於此，這些只是編譯器的一般用途，對於具體的應用，還有更多用途，等待著去發掘。

語言

我們將要設計的語言命名為Stone語言，為什麼取這個名呢，因為我參考了一個叫兩週自制指令碼語言的書籍，不知道書籍怎麼樣，我們拭目以待。實現該開發語言的是java，因此Stone語言也是一種運行於java虛擬機器的語言。

為什麼要叫Stone呢，因為它的靈感來自Ruby和Perl語言的叫法，因為這個語言太過簡陋，不能稱之為寶石，所以叫它石頭。

我們將根據這一個流程來設計語言。下一章，我們將決定Stone語言具備哪些語法功能來適應我們的程式。