Request for 5.4: adding [] as table creation syntax for Lua 6.0

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

Request for 5.4: adding [] as table creation syntax for Lua 6.0

Reed Weichler
I think there was a huge missed opportunity here. [] actually looks like a table!
Reply | Threaded
Open this post in threaded view
|

Re: Request for 5.4: adding [] as table creation syntax for Lua 6.0

Soni "They/Them" L.


On 12/07/16 04:55 PM, Reed Weichler wrote:
> I think there was a huge missed opportunity here. [] actually looks
> like a table!
Except for syntactic simplicity, and not being able to call functions
with it.

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.


Reply | Threaded
Open this post in threaded view
|

Re: Request for 5.4: adding [] as table creation syntax for Lua 6.0

Reed Weichler
IMO it would make the syntax way more simple! The brackets are used for table accesors, why not use the same ones for creation?

The not being able to call functions is a good point though - but I think the benefits outweigh the costs. Wrapping those function calls with () isn't too bad....

Or, we could keep the { } syntax for that very reason. It kind of looks like a middle ground between [] and () anyway. :P

On Tue, Jul 12, 2016 at 12:57 PM, Soni L. <[hidden email]> wrote:


On 12/07/16 04:55 PM, Reed Weichler wrote:
I think there was a huge missed opportunity here. [] actually looks like a table!
Except for syntactic simplicity, and not being able to call functions with it.

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.



Reply | Threaded
Open this post in threaded view
|

Re: Request for 5.4: adding [] as table creation syntax for Lua 6.0

Luiz Henrique de Figueiredo
In reply to this post by Reed Weichler
> I think there was a huge missed opportunity here. [] actually looks like a
> table!

It was like that in Lua 1:
        a = @f[ 10, 20, 30]
was the same as
        t = { 10, 20, 30 }
        f(t)
        a = t
See
        https://www.lua.org/ftp/refman-1.1.ps.gz
        https://www.lua.org/semish94.html
        section "Data types and variables"

Reply | Threaded
Open this post in threaded view
|

Re: Request for 5.4: adding [] as table creation syntax for Lua 6.0

Rena

On Jul 12, 2016 4:36 PM, "Luiz Henrique de Figueiredo" <[hidden email]> wrote:
>
> > I think there was a huge missed opportunity here. [] actually looks like a
> > table!
>
> It was like that in Lua 1:
>         a = @f[ 10, 20, 30]
> was the same as
>         t = { 10, 20, 30 }
>         f(t)
>         a = t
> See
>         https://www.lua.org/ftp/refman-1.1.ps.gz
>         https://www.lua.org/semish94.html
>         section "Data types and variables"
>

If there were going to be new syntax, I feel it'd go well with the discussion of arrays:

t = {x, y, z} --same as current meaning
a = [x, y, z] --means: a = array(x, y, z)
Where array() is something like:

function array(...)
  local t = {...}
  return setmetatable(t, {
    __n = select('#', ...),
    __index = <snip>,
    __newindex = <snip>,
    ...etc...
  })
end

I think Lua would benefit from a "standard" array type, even if it is just a table. (Being standard does also mean the possibility to use a more optimal internal representation.) When everyone rolls their own, interoperability is difficult.

Reply | Threaded
Open this post in threaded view
|

Re: Request for 5.4: adding [] as table creation syntax for Lua 6.0

Coda Highland
On Tue, Jul 12, 2016 at 1:58 PM, Rena <[hidden email]> wrote:

> On Jul 12, 2016 4:36 PM, "Luiz Henrique de Figueiredo"
> <[hidden email]> wrote:
>>
>> > I think there was a huge missed opportunity here. [] actually looks like
>> > a
>> > table!
>>
>> It was like that in Lua 1:
>>         a = @f[ 10, 20, 30]
>> was the same as
>>         t = { 10, 20, 30 }
>>         f(t)
>>         a = t
>> See
>>         https://www.lua.org/ftp/refman-1.1.ps.gz
>>         https://www.lua.org/semish94.html
>>         section "Data types and variables"
>>
>
> If there were going to be new syntax, I feel it'd go well with the
> discussion of arrays:
>
> t = {x, y, z} --same as current meaning
> a = [x, y, z] --means: a = array(x, y, z)
> Where array() is something like:
>
> function array(...)
>   local t = {...}
>   return setmetatable(t, {
>     __n = select('#', ...),
>     __index = <snip>,
>     __newindex = <snip>,
>     ...etc...
>   })
> end
>
> I think Lua would benefit from a "standard" array type, even if it is just a
> table. (Being standard does also mean the possibility to use a more optimal
> internal representation.) When everyone rolls their own, interoperability is
> difficult.

Another advantage of a new syntax for arrays in specific -- and this
is something that had been brought up before; even Roberto commented
on it -- is that array literals can be more efficiently constructed
using a first-class syntax rather than a worker function. A worker
function requires marshalling the members onto the stack and then
iterating through them at runtime, whereas an array literal syntax
would allow constructing the array more-or-less in place with the size
potentially known in advance.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Request for 5.4: adding [] as table creation syntax for Lua 6.0

Dirk Laurie-2
In reply to this post by Reed Weichler
2016-07-12 22:06 GMT+02:00 Reed Weichler <[hidden email]>:

> IMO it would make the syntax way more simple! The brackets are used for
> table accesors, why not use the same ones for creation?

Have you ever written a compiler? Or even just a syntax file for
a text editor?

Syntax is not simpler because you use fewer symbols but overload them.
On the contrary, it becomes a nightmare.

Reply | Threaded
Open this post in threaded view
|

Re: Request for 5.4: adding [] as table creation syntax for Lua 6.0

Thomas Jericke
In reply to this post by Rena
On 07/12/2016 10:58 PM, Rena wrote:

On Jul 12, 2016 4:36 PM, "Luiz Henrique de Figueiredo" <[hidden email]> wrote:
>
> > I think there was a huge missed opportunity here. [] actually looks like a
> > table!
>
> It was like that in Lua 1:
>         a = @f[ 10, 20, 30]
> was the same as
>         t = { 10, 20, 30 }
>         f(t)
>         a = t
> See
>         https://www.lua.org/ftp/refman-1.1.ps.gz
>         https://www.lua.org/semish94.html
>         section "Data types and variables"
>

If there were going to be new syntax, I feel it'd go well with the discussion of arrays:

t = {x, y, z} --same as current meaning
a = [x, y, z] --means: a = array(x, y, z)
Where array() is something like:

function array(...)
  local t = {...}
  return setmetatable(t, {
    __n = select('#', ...),
    __index = <snip>,
    __newindex = <snip>,
    ...etc...
  })
end

I think Lua would benefit from a "standard" array type, even if it is just a table. (Being standard does also mean the possibility to use a more optimal internal representation.) When everyone rolls their own, interoperability is difficult.

As much as I would like that, the syntax clashes with existing statements.

t[1] -- Call t with single element array or indexing with 1?
t[[1,2,3]] -- Call t with string "x" or indexing it with t array?

--
Thomas
Reply | Threaded
Open this post in threaded view
|

Re: Request for 5.4: adding [] as table creation syntax for Lua 6.0

stepa alimov
In reply to this post by Reed Weichler

Reed, why do you want to have different table declaration syntaxes?
12 июля 2016 г. 22:55 пользователь "Reed Weichler" <[hidden email]> написал:
>
> I think there was a huge missed opportunity here. [] actually looks like a table!

Reply | Threaded
Open this post in threaded view
|

Re: Request for 5.4: adding [] as table creation syntax for Lua 6.0

Egor Skriptunoff-2
In reply to this post by Thomas Jericke
On Wed, Jul 13, 2016 at 9:32 AM, Thomas Jericke <[hidden email]> wrote:
On 07/12/2016 10:58 PM, Rena wrote:
If there were going to be new syntax, I feel it'd go well with the discussion of arrays:

t = {x, y, z} --same as current meaning
a = [x, y, z] --means: a = array(x, y, z)
Where array() is something like:

function array(...)
  local t = {...}
  return setmetatable(t, {
    __n = select('#', ...),
    __index = <snip>,
    __newindex = <snip>,
    ...etc...
  })
end

I think Lua would benefit from a "standard" array type, even if it is just a table. (Being standard does also mean the possibility to use a more optimal internal representation.) When everyone rolls their own, interoperability is difficult.

As much as I would like that, the syntax clashes with existing statements.

t[1] -- Call t with single element array or indexing with 1?
t[[1,2,3]] -- Call t with string "x" or indexing it with t array?


The solution is simple: use space to separate lexems.
We already have similar "features" in Lua:
x = t[ [=[a]=]]   -- x = t.a
y = t[[=[a]=]]    -- y = t("=[a]=")

Reply | Threaded
Open this post in threaded view
|

Re: Request for 5.4: adding [] as table creation syntax for Lua 6.0

steve donovan
On Wed, Jul 13, 2016 at 1:41 PM, Egor Skriptunoff
<[hidden email]> wrote:
> The solution is simple: use space to separate lexems.
> We already have similar "features" in Lua:
> x = t[ [=[a]=]]   -- x = t.a
> y = t[[=[a]=]]    -- y = t("=[a]=")

That's really ugly ;) Nah, I like them braces. Can always define a
simple function 'A' or 'T' that applies correct metatable.

If it's a built-in type - well, that's a move away from the simplicity
which remains an attractive part of Lua

Reply | Threaded
Open this post in threaded view
|

Re: Request for 5.4: adding [] as table creation syntax for Lua 6.0

Martin
In reply to this post by Egor Skriptunoff-2

On 16-07-13 04:41 AM, Egor Skriptunoff wrote:
> We already have similar "features" in Lua:
> x = t[ [=[a]=]]   -- x = t.a
> y = t[[=[a]=]]    -- y = t("=[a]=")
>

Yes. And do not forget to add long comments ("--[[]]") to these hash.
And some of you wish to add [] as array declaration. Lua code then be
look like a maze.

Looks like we just ran out of available one-symbol group markers (
(){}[] ). We may extend existing to "long" variable-size versions as
done in quotes. For example "(~(", "{~{", "[~[". But this looks sick. Or
use Unicode. But this is hard.

Reply | Threaded
Open this post in threaded view
|

Re: Request for 5.4: adding [] as table creation syntax for Lua 6.0

Thomas Jericke
In reply to this post by Egor Skriptunoff-2
On 07/13/2016 01:41 PM, Egor Skriptunoff wrote:
On Wed, Jul 13, 2016 at 9:32 AM, Thomas Jericke <[hidden email]> wrote:
On 07/12/2016 10:58 PM, Rena wrote:
If there were going to be new syntax, I feel it'd go well with the discussion of arrays:

t = {x, y, z} --same as current meaning
a = [x, y, z] --means: a = array(x, y, z)
Where array() is something like:

function array(...)
  local t = {...}
  return setmetatable(t, {
    __n = select('#', ...),
    __index = <snip>,
    __newindex = <snip>,
    ...etc...
  })
end

I think Lua would benefit from a "standard" array type, even if it is just a table. (Being standard does also mean the possibility to use a more optimal internal representation.) When everyone rolls their own, interoperability is difficult.

As much as I would like that, the syntax clashes with existing statements.

t[1] -- Call t with single element array or indexing with 1?
t[[1,2,3]] -- Call t with string "x" or indexing it with t array?


The solution is simple: use space to separate lexems.
We already have similar "features" in Lua:
x = t[ [=[a]=]]   -- x = t.a
y = t[[=[a]=]]    -- y = t("=[a]=")


That solves only the second case (and isn't very nice in doing so). But what about the way more common and important first case?

The only good solution I see is to not allow function calls by array constructors. So you would always have to write:
t([])
t([1])
t([1,2])
...

Disallowing only the single element case would be very error prone IMO.
--
Thomas
Reply | Threaded
Open this post in threaded view
|

Re: Request for 5.4: adding [] as table creation syntax for Lua 6.0

Coda Highland
On Wed, Jul 13, 2016 at 10:35 PM, Thomas Jericke <[hidden email]> wrote:
> The only good solution I see is to not allow function calls by array
> constructors. So you would always have to write:
> t([])
> t([1])
> t([1,2])
> ...
>
> Disallowing only the single element case would be very error prone IMO.

I, for one, don't have a problem with this. It certainly won't look
strange; people are used to that kind of syntax.

Another option might be {[ ]}. It's not FANTASTIC, but it's still (1)
obviously a table constructor (though a specialized type) and (2) a
syntax error in current Lua so it won't break any existing code.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Request for 5.4: adding [] as table creation syntax for Lua 6.0

Coda Highland
On Wed, Jul 13, 2016 at 10:52 PM, Coda Highland <[hidden email]> wrote:

> On Wed, Jul 13, 2016 at 10:35 PM, Thomas Jericke <[hidden email]> wrote:
>> The only good solution I see is to not allow function calls by array
>> constructors. So you would always have to write:
>> t([])
>> t([1])
>> t([1,2])
>> ...
>>
>> Disallowing only the single element case would be very error prone IMO.
>
> I, for one, don't have a problem with this. It certainly won't look
> strange; people are used to that kind of syntax.
>
> Another option might be {[ ]}. It's not FANTASTIC, but it's still (1)
> obviously a table constructor (though a specialized type) and (2) a
> syntax error in current Lua so it won't break any existing code.
>
> /s/ Adam

... Bleh, I say that, and then I realize how much of an issue it could
be in terms of actually parsing the grammar, due to the ambiguity of
{[ 1 ]} and { [1] = 2 }. I haven't hacked on Lua's parser itself to
know how much of an issue it would be to handle that production (it
requires an unbounded amount of lookahead to do it with an LL or LR
parser but it might not be a problem with Lua's parser implementation
-- it wouldn't be a problem with the parser architecture I built
myself for a class).

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Request for 5.4: adding [] as table creation syntax for Lua 6.0

Egor Skriptunoff-2
In reply to this post by Rena
On Tue, Jul 12, 2016 at 11:58 PM, Rena <[hidden email]> wrote:

On Jul 12, 2016 4:36 PM, "Luiz Henrique de Figueiredo" <[hidden email]> wrote:
> It was like that in Lua 1:
>         a = @f[ 10, 20, 30]
> was the same as
>         t = { 10, 20, 30 }
>         f(t)
>         a = t
>

If there were going to be new syntax, I feel it'd go well with the discussion of arrays:

t = {x, y, z} --same as current meaning
a = [x, y, z] --means: a = array(x, y, z)
Where array() is something like:

function array(...)
  local t = {...}
  return setmetatable(t, {
    __n = select('#', ...),
    __index = <snip>,
    __newindex = <snip>,
    ...etc...
  })
end

I think Lua would benefit from a "standard" array type, even if it is just a table. (Being standard does also mean the possibility to use a more optimal internal representation.) When everyone rolls their own, interoperability is difficult.

Maybe, {1, 2, 3} for tables, @{1, 2, 3} for arrays (with array metatable applied)?
Reply | Threaded
Open this post in threaded view
|

Re: Request for 5.4: adding [] as table creation syntax for Lua 6.0

Daurnimator
On 14 July 2016 at 17:43, Egor Skriptunoff <[hidden email]> wrote:

> On Tue, Jul 12, 2016 at 11:58 PM, Rena <[hidden email]> wrote:
>>
>> On Jul 12, 2016 4:36 PM, "Luiz Henrique de Figueiredo"
>> <[hidden email]> wrote:
>> > It was like that in Lua 1:
>> >         a = @f[ 10, 20, 30]
>> > was the same as
>> >         t = { 10, 20, 30 }
>> >         f(t)
>> >         a = t
>> >
>>
>> If there were going to be new syntax, I feel it'd go well with the
>> discussion of arrays:
>>
>> t = {x, y, z} --same as current meaning
>> a = [x, y, z] --means: a = array(x, y, z)
>> Where array() is something like:
>>
>> function array(...)
>>   local t = {...}
>>   return setmetatable(t, {
>>     __n = select('#', ...),
>>     __index = <snip>,
>>     __newindex = <snip>,
>>     ...etc...
>>   })
>> end
>>
>> I think Lua would benefit from a "standard" array type, even if it is just
>> a table. (Being standard does also mean the possibility to use a more
>> optimal internal representation.) When everyone rolls their own,
>> interoperability is difficult.
>
> Maybe, {1, 2, 3} for tables, @{1, 2, 3} for arrays (with array metatable
> applied)?

In that case, why not use the already valid: S(1,2,3)

Reply | Threaded
Open this post in threaded view
|

Re: Request for 5.4: adding [] as table creation syntax for Lua 6.0

Thomas Jericke
On 07/14/2016 10:01 AM, Daurnimator wrote:

> On 14 July 2016 at 17:43, Egor Skriptunoff <[hidden email]> wrote:
>> On Tue, Jul 12, 2016 at 11:58 PM, Rena <[hidden email]> wrote:
>>> On Jul 12, 2016 4:36 PM, "Luiz Henrique de Figueiredo"
>>> <[hidden email]> wrote:
>>>> It was like that in Lua 1:
>>>>          a = @f[ 10, 20, 30]
>>>> was the same as
>>>>          t = { 10, 20, 30 }
>>>>          f(t)
>>>>          a = t
>>>>
>>> If there were going to be new syntax, I feel it'd go well with the
>>> discussion of arrays:
>>>
>>> t = {x, y, z} --same as current meaning
>>> a = [x, y, z] --means: a = array(x, y, z)
>>> Where array() is something like:
>>>
>>> function array(...)
>>>    local t = {...}
>>>    return setmetatable(t, {
>>>      __n = select('#', ...),
>>>      __index = <snip>,
>>>      __newindex = <snip>,
>>>      ...etc...
>>>    })
>>> end
>>>
>>> I think Lua would benefit from a "standard" array type, even if it is just
>>> a table. (Being standard does also mean the possibility to use a more
>>> optimal internal representation.) When everyone rolls their own,
>>> interoperability is difficult.
>> Maybe, {1, 2, 3} for tables, @{1, 2, 3} for arrays (with array metatable
>> applied)?
> In that case, why not use the already valid: S(1,2,3)
>

Because S is only known at run time. That  means you can't improve the
parser to generate arrays directly.

This is of course only important if the array type implementation is
actually in some way optimized. Ideally it wouldn't
rely on metatables at all.
--
Thomas

Reply | Threaded
Open this post in threaded view
|

Re: Request for 5.4: adding [] as table creation syntax for Lua 6.0

Egor Skriptunoff-2
In reply to this post by Daurnimator
On Thu, Jul 14, 2016 at 11:01 AM, Daurnimator <[hidden email]> wrote:
On 14 July 2016 at 17:43, Egor Skriptunoff <[hidden email]> wrote:
> On Tue, Jul 12, 2016 at 11:58 PM, Rena <[hidden email]> wrote:
>>
>> On Jul 12, 2016 4:36 PM, "Luiz Henrique de Figueiredo"
>> <[hidden email]> wrote:
>> > It was like that in Lua 1:
>> >         a = @f[ 10, 20, 30]
>> > was the same as
>> >         t = { 10, 20, 30 }
>> >         f(t)
>> >         a = t
>> >
>>
>> If there were going to be new syntax, I feel it'd go well with the
>> discussion of arrays:
>>
>> t = {x, y, z} --same as current meaning
>> a = [x, y, z] --means: a = array(x, y, z)
>> Where array() is something like:
>>
>> function array(...)
>>   local t = {...}
>>   return setmetatable(t, {
>>     __n = select('#', ...),
>>     __index = <snip>,
>>     __newindex = <snip>,
>>     ...etc...
>>   })
>> end
>>
>> I think Lua would benefit from a "standard" array type, even if it is just
>> a table. (Being standard does also mean the possibility to use a more
>> optimal internal representation.) When everyone rolls their own,
>> interoperability is difficult.
>
> Maybe, {1, 2, 3} for tables, @{1, 2, 3} for arrays (with array metatable
> applied)?

In that case, why not use the already valid: S(1,2,3)

Three reasons:
1) Standardization of array type in Lua (all the developers will use the same implementation of arrays)
2) Avoidance of performance penalty due to passing vararg to a function
3) Avoiding the limitation on number of function arguments

Reply | Threaded
Open this post in threaded view
|

Re: Request for 5.4: adding [] as table creation syntax for Lua 6.0

steve donovan
On Thu, Jul 14, 2016 at 10:13 AM, Egor Skriptunoff
<[hidden email]> wrote:
> Three reasons:
> 1) Standardization of array type in Lua (all the developers will use the
> same implementation of arrays)
> 2) Avoidance of performance penalty due to passing vararg to a function
> 3) Avoiding the limitation on number of function arguments

Valid reasons, and I like the @{...} notation. This new type (as I
understand) will be a proper array (no hash part) and will not suffer
from the hard-to-explain holes issue.

So this would be valid for all possible argument values?

function foo(...)
   local args = @{...}
   print(#args)
   forward(...)
end

But how would this help the forwarding problem?

A new feature must provide enough power and clarity to get around the
'explanation overhead'. Otherwise, it's optimizing a special case.

12