Literal values and __call

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

Literal values and __call

John Erling Blad
I wonder if the following could be changed

  args ::=  ‘(’ [explist] ‘)’ | tableconstructor | LiteralString

It is in the doc [1] and is somewhat limiting. It would be better if
it included all literal values, and I can't see how this could be a
problem, but perhaps there are some other reason why this is
disallowed?

[1] https://www.lua.org/manual/5.3/manual.html#8

Reply | Threaded
Open this post in threaded view
|

Re: Literal values and __call

nobody
On 05/06/2019 23.13, John Erling Blad wrote:

> I wonder if the following could be changed
>
>    args ::=  ‘(’ [explist] ‘)’ | tableconstructor | LiteralString
>
> It is in the doc [1] and is somewhat limiting. It would be better if
> it included all literal values, and I can't see how this could be a
> problem, but perhaps there are some other reason why this is
> disallowed?
>
> [1] https://www.lua.org/manual/5.3/manual.html#8

Lua doesn't do static typing, which means that in order to somewhat
reliably detect typos at compile time, it needs a larger amount of
syntactically invalid programs.

There's already the problem that `local x, y z = 1, 2, 3` results in a
global variable `z = 1` and empty locals `x, y`.  (I once spent far too
much time searching for this one, still painfully remembered…)

Permitting any literals as unparenthesized arguments would mean that
`local x, y, z = foo 23, 42` would be interpreted as a function call.
(Same for argument lists of function calls, multiple return values,
table constructors…)

I suspect that the trade-off between space/time saved on getting rid of
the parentheses vs. extra time spent searching typos that are now run
time instead of compile time errors is not in favor of this change.

-- nobody

Reply | Threaded
Open this post in threaded view
|

Re: Literal values and __call

John Erling Blad
Perhaps I wasn't clear enough, but `foo "bar"` is a valid construct, while `foo 42` is not, which is inconsistent. Either all literals should be allowed in such constructs or none.

ons. 5. jun. 2019, 23.49 skrev nobody <[hidden email]>:
On 05/06/2019 23.13, John Erling Blad wrote:
> I wonder if the following could be changed
>
>    args ::=  ‘(’ [explist] ‘)’ | tableconstructor | LiteralString
>
> It is in the doc [1] and is somewhat limiting. It would be better if
> it included all literal values, and I can't see how this could be a
> problem, but perhaps there are some other reason why this is
> disallowed?
>
> [1] https://www.lua.org/manual/5.3/manual.html#8

Lua doesn't do static typing, which means that in order to somewhat
reliably detect typos at compile time, it needs a larger amount of
syntactically invalid programs.

There's already the problem that `local x, y z = 1, 2, 3` results in a
global variable `z = 1` and empty locals `x, y`.  (I once spent far too
much time searching for this one, still painfully remembered…)

Permitting any literals as unparenthesized arguments would mean that
`local x, y, z = foo 23, 42` would be interpreted as a function call.
(Same for argument lists of function calls, multiple return values,
table constructors…)

I suspect that the trade-off between space/time saved on getting rid of
the parentheses vs. extra time spent searching typos that are now run
time instead of compile time errors is not in favor of this change.

-- nobody

Reply | Threaded
Open this post in threaded view
|

Re: Literal values and __call

John Erling Blad
I could not reproduce the claimed bug. On which version does it exist?

tor. 6. jun. 2019, 00.30 skrev John Erling Blad <[hidden email]>:
Perhaps I wasn't clear enough, but `foo "bar"` is a valid construct, while `foo 42` is not, which is inconsistent. Either all literals should be allowed in such constructs or none.

ons. 5. jun. 2019, 23.49 skrev nobody <[hidden email]>:
On 05/06/2019 23.13, John Erling Blad wrote:
> I wonder if the following could be changed
>
>    args ::=  ‘(’ [explist] ‘)’ | tableconstructor | LiteralString
>
> It is in the doc [1] and is somewhat limiting. It would be better if
> it included all literal values, and I can't see how this could be a
> problem, but perhaps there are some other reason why this is
> disallowed?
>
> [1] https://www.lua.org/manual/5.3/manual.html#8

Lua doesn't do static typing, which means that in order to somewhat
reliably detect typos at compile time, it needs a larger amount of
syntactically invalid programs.

There's already the problem that `local x, y z = 1, 2, 3` results in a
global variable `z = 1` and empty locals `x, y`.  (I once spent far too
much time searching for this one, still painfully remembered…)

Permitting any literals as unparenthesized arguments would mean that
`local x, y, z = foo 23, 42` would be interpreted as a function call.
(Same for argument lists of function calls, multiple return values,
table constructors…)

I suspect that the trade-off between space/time saved on getting rid of
the parentheses vs. extra time spent searching typos that are now run
time instead of compile time errors is not in favor of this change.

-- nobody

Reply | Threaded
Open this post in threaded view
|

Re: Literal values and __call

Egor Skriptunoff-2
In reply to this post by John Erling Blad
On Thu, Jun 6, 2019 at 12:14 AM John Erling Blad wrote:
It would be better if
it included all literal values, and I can't see how this could be a
problem, but perhaps there are some other reason why this is
disallowed?



What should "x=x-1" mean then?
x = x(-1)
or
x = x - 1
?
Reply | Threaded
Open this post in threaded view
|

Re: Literal values and __call

John Erling Blad
Left side of assignment in previous example, that is the assumption “What should "x=x-1" mean then?”, has an inherent bug. The variable  "x" is not a number.

Assume you have

local h = {}
local mt = {}
function mt:__call( arg ) return arg end
setmetatable( h, mt )
return h


then

  foo = foo( -1 ) -- reassign foo = -1
  foo = foo 1 -- unexpected symbol
  foo = foo -1 -- attempt to perform arithmetic on local
 foo = foo - 1 -- attempt to perform arithmetic on local

Next call after reassign will fail. Third and fourth statement can be fixed with a sub and add metamethod.

The second statement fails due to the parser, and can't be fixed.

Now rewrite as similar and syntactically valid statements with strings

  foo = foo( 'bar' ) -- reassign foo = 'bar'
  foo = foo 'bar' -- reassign foo = 'bar'
  foo = foo .. 'bar' -- attempt to concatenate local

Next call after reassign will fail. Third statement can be fixed with a concat metamethod.


On Thu, Jun 6, 2019 at 10:25 PM Egor Skriptunoff <[hidden email]> wrote:
On Thu, Jun 6, 2019 at 12:14 AM John Erling Blad wrote:
It would be better if
it included all literal values, and I can't see how this could be a
problem, but perhaps there are some other reason why this is
disallowed?



What should "x=x-1" mean then?
x = x(-1)
or
x = x - 1
?