8 messages
Open this post in threaded view
|

 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, }
Open this post in threaded view
|

## Re: Question about table syntax

 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
Open this post in threaded view
|

## Re: Question about table syntax

 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
Open this post in threaded view
|

## Re: Question about table syntax

 сб, 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
Open this post in threaded view
|

## Re: Question about table syntax

 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! :)
Open this post in threaded view
|

## Re: Question about table syntax

 > 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.