|
Using Lua 5.3. Code: return { 1 } [1] Result: <eof> expected near '[' Code: return ( { 1 } ) [1] Result: 1 The question is, why is the first version not accepted? I am not asking for an explanation why the details are such and such, but rather for a rationale, if there is one, that a table "literal" (constructor) should not appear in some expressions unless it is wrapped in parentheses.For regularity, what can come before [exp] is the same stuff that can come before (explist), forming function calls. Allowing {1}[1] would also allow {1}(1), which being a function call could be used as a statement: a = b {1}(1) -- "calling" table {1} That would create another ambiguity in the grammar, similar to the (already present) ambiguity with parentheses: a = b (print)(1) -- calling print or calling b? We chose to reduce ambiguities. Note too that all other "literals" also cannot be used in that position: 4[1]; "hello"[1]; true[1]; nil[1] But, in the end, it all boils down to taste. -- Roberto
I made a patch for Lua 5.2 to make those brackets optional. To be backwards compatible, I excluded that call operator.
You find that patch here.
http://lua-users.org/wiki/ThomasJericke
My basic idea back than was to have type notation similar to UML notation:
163764 : uint32 would than create a uint32 userdate that stores 16376, this by registering all conversion function to the metatable of the type number. I never continued the approach as I don't think that breaking compatibility to vanilla Lua is worth the benefit of an arguably nicer syntax.
--
Thomas