[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Request for 5.4: adding [] as table creation syntax for Lua 6.0
- From: Coda Highland <chighland@...>
- Date: Tue, 12 Jul 2016 14:33:13 -0700
On Tue, Jul 12, 2016 at 1:58 PM, Rena <hyperhacker@gmail.com> wrote:
> On Jul 12, 2016 4:36 PM, "Luiz Henrique de Figueiredo"
> <lhf@tecgraf.puc-rio.br> 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