kl中的錯誤處理
之前我一直說錯誤處理是kl里的軟肋，由于一直在關注一些具體功能的改進，也沒有對
這方面進行改善。
我這里所說的錯誤處理，包括語言本身和作為庫本身兩方面。
語言本身指的是對于腳本代碼里的各種語法錯誤、運行時錯誤等的處理。好的處理應該
不僅僅可以報告錯誤，而且還能忽視錯誤讓處理過程繼續。
而把kl解釋器作為一個庫使用時，庫本身也應該對一些錯誤情況進行報告。
整體上，kl簡單地通過回調函數指針來把錯誤信息傳給庫的應用層。而因為我希望整個
kl實現的幾層（詞法分析、語法分析、符號表、解釋器等）可以盡可能地獨立。例如雖然語
法分析依賴于詞法分析（依賴于詞法分析提供的接口），但是因為詞法分析并不對語法分析
依賴，所以完全可以把詞法分析模塊拿出來單獨使用。所以，在日志方面，我幾乎為每一層
都附加了個error_log函數指針。
而用戶層在通過kllib層使用整個庫時，傳入的回調函數會被間接地傳到詞法分析層。
實際上，當kl作為一個庫時，kllib正是用于橋接庫本身和用戶層的bridge。
另一方面，語言本身在處理錯誤的腳本代碼時，錯誤分為幾大類型層次：
1.詞法錯誤 lex error，如掃描字符串出錯
2.語法錯誤 syntax error，整理語法樹時出錯
3.運行時錯誤 runtime error，在解釋執行代碼時出錯
4.庫錯誤 lib error，發生在kllib這個bridge層的錯誤
kl在報告錯誤信息時，會首先附加該錯誤是什么類型的錯誤。
這里最麻煩的是語法錯誤的處理。因為語法分析時發生錯誤的可能性最大，錯誤類型也
有很多。例如你少寫了分號，少寫了括號，都會導致錯誤。這個階段發生錯誤不僅要求能準
確報告錯誤，還需要忽略錯誤讓整個過程盡量正確地下去。
語法分析階段最根本的就是符號推導（單就kl的實現而言），所謂的符號推導是這樣一
個過程，例如有賦值語句：a = 1;語法分析時，語法分析器希望（所謂的推導）等號后面會
是一個表達式，當分析完了表達式后，又希望接下來的符號(token)是分號作為該語句的結
束。
所以，klparser.c中的syn_match正是完成這個過程。每次你傳入你希望的符號，例如
分號，該函數就檢查詞法分析中當前符號(token)是否是分號。當然，對于正確的腳本代碼，
它是一個分號，但是如果是錯誤的代碼，syn_match就會打印諸如：
>>syntax error->unexpected token-> ....
即當前的符號是不被期望的。
上面完成了錯誤的檢測。對于錯誤的忽略，或者更高級點地對錯誤的校正，kl中處理得
比較簡單，即：直接消耗掉這個不是期望中的符號。例如：
a = 1 /* 忘加了分號 */
b = 1;
上面兩句代碼被處理時，在處理完a=1后，發現當前的符號(token)b(是一個ID token)不
是期望(expect)中的分號，首先報告b不是期望的符號，然后kl直接掠過b，獲取下個符號=。
然后處理a=1這個過程結束。當然，下次處理其他語句時，發現=符號，又會繼續發生錯誤。
錯誤信息中比較重要的還有行號信息。之前kl這方面一直存在BUG，我在寫貪食蛇例子
的時候每次新加代碼都不敢加太多。因為解釋器報告的錯誤行號總是錯誤的，我只能靠有沒
有錯誤來找錯誤，而不能通過錯誤信息找錯誤。
行號信息被保存在詞法分析狀態中(lexState:lineno)，語法分析中獲取token時，會取
出當前的行號，保存到語法樹樹節點中。因為包括解釋模塊都是基于樹節點的，所以詞法分
析語法分析解釋器三層都可以準確報告行號。
但是之前解釋器報告的行號始終很詭異。癥結在于我在載入腳本代碼文件時，以rb方式
載入，即二進制形式。于是，在windows下，每行文本尾都會有\r\n兩個字符。而在詞法分
析階段對于行號的增加是：
case '\n':
case '\r':
ls->lineno ++;
不同OS對于文本文件的換行所添加的字符都不一樣，例如windows用\r\n，unix系用\n
，貌似Mac用\r。所以，詞法分析這里寫應該可以準確地處理行號。
但是對于windows，這里就直接將行號增加了兩次，所以也就導致了行號出錯的問題。查
了下文檔，發現以文本方式打開文件("r")，調用fread函數讀入文件內容時，就會自動把
\r\n替換為\n。
代碼改后，又出問題。這個時候，通過fseek和ftell獲取到的文件尺寸，貌似包括了
\r\n，而fread出來的內容卻因為替換\r\n為\n而沒有這么多。
不過文件載入不屬于kl庫本身，kl只接收以字符串形式表示的腳本代碼，所以也算不了
核心問題。
同樣，最新代碼可以從google SVN獲取。當然，我也在考慮是否換一個新的項目地址。