Re: Expanding multiple return values of Lua functions in a Lua table constructor

[Dirk Laurie <dirk.laurie@...>]

2012/10/18 Daurnimator <quae@daurnimator.com>:
> On 18 October 2012 06:28, agentzh <agentzh@gmail.com> wrote:
>> I'm afraid the current behaviour is quite unintuitive. Opinions?
>>
>> Thanks!
>> -agentzh
>>
>
> This question comes up regulary, and the answer always seems to be
> "its intuitive the way it is".
> The number of threads about it suggest this is not the case.

The way it is, is convenient rather than intuitive. If I write
`t={a(),b(),"third"}` I will get terribly confused if `t[3]` could be
something else than `"third"`.

> I hope that we can revisit this for the next lua version.

It is not confined to table constructors. The problem is that `tuple`
is not a Lua type, even though it is part of the language (multiple
assignment, multiple returns from a function, argument lists, `...`
in a function).

In these situations, we do not need a Lua type: an obvious
implementation of a tuple is simply some consecutive slots
on the stack, No stores to elsewhere required.

What about a syntactic construction that avoids the adjustment
to one value?  At present `(lst)` forces the adjustment; similarly
`[lst]` could force the non-adjustment.  If used only in the situations
where tuples occur, there should not be a lexing conflict.  The explicit
appearance of the brackets would warn the reader that after
`t={[a()],[b()],"third"}` something other than `t[3]` might be`"third"`.