Lua5.0的語法非常簡潔，這從參考手冊中的語法定義的規模(轉換成標準BNF形式大概有100個左右的產生 式)可以看出。不過簡潔歸簡潔，它卻不完全是無二義性的。下面將用具體例子揭示什么樣的代碼會引起歧義(執行環境是www.lua.org發布的 Lua5.04)。

首先定義如下幾個函數:

function foo(a) 
print("foo print",a) 
return a 
end 
function goo(a) 
print("goo print",a) 
return a 
end 
function hoo(a) 
print("hoo print",a) 
return a 
end 

試看這一段代碼：

foo(goo)

(hoo)(1979)

如果試圖編譯執行上面這段程序，那么解釋器就會報告 "ambiguous syntax (function call x new statement) near '(' " 這樣的錯誤。為什么呢?或許寫程序的人原本的意思就是***行foo(goo)為一個單獨的函數調用語句(statement)，而第二行(hoo) (1979)又為另一個單獨的函數調用語句(Lua中語句之間的分隔符——分號并非必需，而是可選的)。但是不要忘記了foo(goo)(hoo)是一個 語法上完全合法的函數調用形式(在編譯過程中換行符作為空白符會被忽略掉)，foo(goo)(hoo)(1979)也可以成為一個完整的函數調用語句。 這樣的話，編譯器就無法知道程序員的真正意圖了。

我們可以再深入到編譯過程里頭一點看看。Lua語法的形式定義(轉換成BNF標準形式)包含如下幾個產生式：

(1) stat -> functioncall (語句的產生式)

(2) prefixexp -> functioncall (前綴表達式的產生式)

(3) functioncall -> prefixexp args

| prefixexp ':' Name args (函數調用的產生式)

可以發現，functioncall既可以被規約(reduce)為stat，也可以被規約成prefixexp，(1)和(2)兩個產生式發生了沖突，編譯器不知道用哪一個對foo(goo)進行規約，所以便出現了錯誤。

其實要解決這個問題歧義問題也很簡單，在***行后面加一個語句分隔符——分號，編譯器就會把代碼編譯成兩個獨立的語句。或者把兩行合并成一行， 那么foo(goo)(hoo)(1979)就被看作是一個完整的函數調用(其實此時仍然是有歧義的，但是Lua5.04通過優先選擇prefixexp -> functioncall進行規約解決了二義性)。

實際上，還有另外3種情況也會引起歧義：

-- prefixexp -> functioncall 與 　　
-- exp -> functioncall 沖突。 　　
-- 編譯器不知道該把foo(goo)解釋成表達式(exp)還是前綴表達式 　　
local v = foo(goo) 　　(hoo)(1979) 　　
-- exp -> var 與 prefixexp -> var 沖突 　　
-- 第二行的變量(var)m不知道該被看成表達式還是前綴表達式 　　
m = foo 　　local v = m 　　(goo)(1979) 　　
-- prefixexp -> '(' exp ')' 與 　　
-- exp -> '(' exp ')' 沖突 　　
-- 不知道該把(t.fn)看成表達式還是前綴表達式 　　
t = {fn = foo} 　　local v = (t.fn) 　　(goo)(1979) 

***個例子中解決歧義的兩種方法同樣也適用于這三種情況。至此我們不難發現，引起歧義的根本原因在于Lua語句之間的分隔符是可選而不是必需的。如果強制 要求象C語言那樣每條語句后跟一個分號，那么二義性就不復存在(這一點在本文作者構造Lua5.0的SLR解析表時得到了驗證)。但是有許多人未必喜歡敲 入那么多討厭的分號，所以Lua的作者把選擇的權利留給了程序員自己，付出的代價就是引進了這些模糊的代碼(雖然出現的幾率不大)，這也算是語言設計時的 一種折衷吧。

原文鏈接：http://tech.it168.com/j/2008-02-17/200802171001717.shtml