Question about table syntax

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Question about table syntax

Sergey Kovalev
Lua allows to separate statements with semicolons. But works perfect
without them.
So I can write instead
a=1;b=2;c=3;
simply
a=1 b=2 c=3

Will it break anything if lua will behave same way with tables?

t={ a=1 b=2 c=3 }

instead of

t={ a=1, b=2, c=3, }

Reply | Threaded
Open this post in threaded view
|

Re: Question about table syntax

nobody
On 16/08/2019 23.25, Sergey Kovalev wrote:
> Lua allows to separate statements with semicolons. Will it break
> anything if lua will behave same way with tables?
>
> t={ a=1 b=2 c=3 }

t = { u = v [w] = x }

-- nobody

Reply | Threaded
Open this post in threaded view
|

Re: Question about table syntax

Philippe Verdy
  t= { y = sin x };
  t= { y = sin, x };
Lot of ambiguities will happen, even when you don't specify the keys:
  t = { sin 0 };
  t = { sin, 0 };
or:
  t = { 12 - 1 };
  t = { 12, - 1 };
The way by which semicolons were made optional between statements in Lua is already broken, but more limited; the colon separators in table data initializers would be much worse (in fact there are all the same ambiguities if you drop the semicolons between function parameters, or between return values, or between multiple right-hand side values of an assignment, it would make the language extremely ambiguous with lots of caveats in the parser, or forcing it to use backtrailing and maintaining a complex structure to memoize the backtrailing state)

Le ven. 16 août 2019 à 23:37, nobody <[hidden email]> a écrit :
On 16/08/2019 23.25, Sergey Kovalev wrote:
> Lua allows to separate statements with semicolons. Will it break
> anything if lua will behave same way with tables?
>
> t={ a=1 b=2 c=3 }

t = { u = v [w] = x }

-- nobody

Reply | Threaded
Open this post in threaded view
|

Re: Question about table syntax

Sergey Kovalev
сб, 17 авг. 2019 г. в 06:30, Philippe Verdy <[hidden email]>:
>
>   t= { y = sin x };
>   t= { y = sin, x }
here is no ambiguities
> Lot of ambiguities will happen, even when you don't specify the keys:
>   t = { sin 0 };
Here is no ambiguities
>   t = { sin, 0 };
> or:
>   t = { 12 - 1 };
This will be t= { 11 }
>   t = { 12, - 1 };

> The way by which semicolons were made optional between statements in Lua is already broken, but more limited; the colon separators in table data initializers would be much worse (in fact there are all the same ambiguities if you drop the semicolons between function parameters, or between return values, or between multiple right-hand side values of an assignment, it would make the language extremely ambiguous with lots of caveats in the parser, or forcing it to use backtrailing and maintaining a complex structure to memoize the backtrailing state)

All ambiguities could fixed with explicit comma
Main aim is functions groups
  f1=function() end
  --
  f100500=function() end
They could be easily moved into table and back
t={
  f1=function() end
  --
  f100500=function() end
}
without any additional editing.
Now it could be done with construction like this

t={} do local _ENV=setmetatable(t,{__index=_ENV})
    function f1() end
    --
    function f100500() end
end

Reply | Threaded
Open this post in threaded view
|

Re: Question about table syntax

szbnwer@gmail.com
hi there! :)

`{sin x}` is safe, but if `x` is a string or a table (not held by the
variable `x`) then it will fail, or even `(...)` as an argument that
is about trimming the values after the 1st one would fail... or `{fun
(whatever).. somethingElse}` would fail...


about tables of functions:
```
lotsaFun={
function() end;
function() end;
function() end;
}
```


random halfway related idea:
ive also seen configs that require/allow `;` as a separator ([bash,
ini]?!) for key-value pairs can be used like `loadstring('return {'..
readFile(conf).. '}')` (if i just wrote what i actually wanted :D )


otherwise if anything like this should happen, i would still prefer to
see (nope, not really that much, but a weak maybe) newlines as
separators, something like in js, but i think ive left a not really
satisfied message in the near past under that topic... but maybe we
could even enjoy it, who knows, i still use `;` in js but not in lua
:D

have fun, bests! :)

Reply | Threaded
Open this post in threaded view
|

Re: Question about table syntax

Jim-2
> otherwise if anything like this should happen, i would still prefer to
> see (nope, not really that much, but a weak maybe) newlines as
> separators, something like in js

i do not like the idea of giving special meaning to newlines
(often abused as statement terminators) or any other whitespace token.


Reply | Threaded
Open this post in threaded view
|

Re: Question about table syntax

szbnwer@gmail.com
hi Jim! :)

> i do not like the idea of giving special meaning to newlines
(often abused as statement terminators) or any other whitespace token.

sure thing! :) otoh we can miraculously live with javascript and the
world is not burning in flames because its terminators, but cuz
everything else :D

https://www.dropbox.com/s/j98f8p79fkb9l8a/pontosvessz%C5%91.png
it says "this semicolon is misplaced" (sorry for dropbox, imgur wanted
me to register or i missed the right way)

bests! :)

Reply | Threaded
Open this post in threaded view
|

Re: Question about table syntax

Philippe Verdy
I fact this suppression of commas is a vary bad idea: instead of attempting to remove commas conditionally, it's highly preferable to use the comma always, even at end of a comma-separated list: Lua already supports the last comma not followed by any expression and not followed by another comma, as being ignorable).
So for tables of functions, in source code coming from code generators, just terminate all of them with a comma and you are safe. We never need to drop these commas and introduce new parsing ambiguities.

Also the idea if special meanings to "any whitespace" is very bad (Javascript does not tolerate it, it gives special meaning ONLY to sequence of whitespaces/comments containing at least one newline as a possible statement terminator, i.e. treated like a ";", in specific parts of the syntax; unfortunately this is not true for Lua that treats ALL sequences of whitespaces, possibly including comments, as a token separator without any syntaxic role, and then the Lua parser has to disambiguate statement termination when this could be continued in the next line or the same line for "currified" function calls). currified expressions should have never been allowed in Lua, except inside parentheses or in comma-separated lists, for function call parameters or table initializers.

But adding new similar ambiguities for the commas (like for the semicolon) by making them optional would be even worse, with dramatic unpredicable effects for code generators and code parsers!

Le sam. 17 août 2019 à 17:35, [hidden email] <[hidden email]> a écrit :
hi Jim! :)

> i do not like the idea of giving special meaning to newlines
(often abused as statement terminators) or any other whitespace token.

sure thing! :) otoh we can miraculously live with javascript and the
world is not burning in flames because its terminators, but cuz
everything else :D

https://www.dropbox.com/s/j98f8p79fkb9l8a/pontosvessz%C5%91.png
it says "this semicolon is misplaced" (sorry for dropbox, imgur wanted
me to register or i missed the right way)

bests! :)