[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: indexing of new created tables
- From: Peter Melnichenko <mpeterval@...>
- Date: Fri, 25 Aug 2017 11:22:57 +0300
On Fri, Aug 25, 2017 at 10:24 AM, Michael Rosenberg <rosenbmi@umich.edu> wrote:
> Sorry to revive an old thread. Here's an ambiguity you would introduce into the grammar if you implemented the rule
> var ::= Name | tableconstructor ‘[’ exp ‘]’ | prefixexp ‘[’ exp ‘]’ | prefixexp ‘.’ Name
> Consider the following
>
> function foo(_)
> return {"x", "y", "z"}
> end
> v = foo {"a", "b", "c"} [2]
> print(type(v))
>
> What is printed? If {"a", "b", "c"}[2] is evaluated first, then foo("b") is a table. If foo {"a", "b", "c"} is evaluated first, then {"x", "y", "z"}[2] is a string. The same ambiguous situation happens with the use of the dot operator and the colon operator.
This is not ambiguous. `functioncall` requires `args` at the end, and
`args` can only match `{"a", "b", "c"}` here, not `{"a", "b",
"c"}[2]`. So the indexing can't be an argument, and it can't be a
standalone statement either.
If you add another call at the end, that makes it ambiguous: `v = f
{g} [1] ()` could be a single statement or two, equivalent to `v = f;
{g} [1] ()`. This is similar to how `v = f (g) (h)` is ambiguous in
original Lua grammar.
Ref:
functioncall ::= prefixexp args | prefixexp ‘:’ Name args
args ::= ‘(’ [explist] ‘)’ | tableconstructor | LiteralString
-- Peter