lua-users home
lua-l archive

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


On Thu, Jul 14, 2016 at 11:01 AM, Daurnimator <quae@daurnimator.com> wrote:
On 14 July 2016 at 17:43, Egor Skriptunoff <egor.skriptunoff@gmail.com> wrote:
> On Tue, Jul 12, 2016 at 11:58 PM, Rena <hyperhacker@gmail.com> wrote:
>>
>> On Jul 12, 2016 4:36 PM, "Luiz Henrique de Figueiredo"
>> <lhf@tecgraf.puc-rio.br> 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