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的作者把选择的权利留给了程序员自己，付出的代价就是引进了这些模糊的代码(虽然出现的几率不大)，这也算是语言设计时的一种折衷吧。
