lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


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