[Proposal] Table literal indexing (Was: Re: [Proposal] .name global indexing (Was: Re: 'with' statement))

[Andrew Cannon <ajc@...>]

On 13/03/16 21:05, Alloyed wrote:
> 
> 
> On 03/12/2016 05:37 PM, Andrew wrote:
>> On 12/03/16 17:02, Rena wrote:
>>> On Mar 12, 2016 9:57 AM, "Andrew Cannon" <ajc@gmx.net <mailto:ajc@gmx.net>> wrote:
>>>>
>>>> On 11/03/16 09:24, Dirk Laurie wrote:
>>>>> 2016-03-10 17:55 GMT+02:00 Coda Highland <chighland@gmail.com
>>> <mailto:chighland@gmail.com>>:
>>>>>
>>>>>> At this point you might as well use _.a = 1 and then you no longer
>>>>>> even need a with statement.
 [snip]
>>>>
>>>> Perhaps this syntax could be extended to allow already initialized table members
>>>> to be used in initialization later members, a feature which I have sometimes
>>> missed:
>>>>
>>>> eg:
>>>>
>>>> local t = {
>>>>         a = x1 * x2,
>>>>         b = _.a + 1
>>>> }
>>>>
>>>> The '_' in this case would reference the table currently being built.
>>>>
>>>> Andrew
>>>>
>>>>
>>> I think `b = t.a + 1` would be more natural, but I don't know how doable it is.
>>>
>>
>> ok, bad example! - consider:
>>
>> func( { a = x1 * x2; b = _.a + 1} )
>>
>> -a
>>
>>
> How about something like:
> 
> function with(t, fn)
>   setfenv(fn, t)
>   fn()
>   return t
> end
> 
> local t = with({}, function()
>   a = x1 * x2
>   b = a + 1
> end)
> 
> I don't like the idea that the order of a table literal might matter,
> especially for cases where tables are generated by code.
> 

I can't really agree with your objection - after all, the order of things in a
program _is_ generally significant, so why shouldn't this apply to a table
literal too. The order of indexed (array) entries matters already.

What's interesting about this syntax is that you can build much more complex
structures directly in a table literal, which should allow the compiler to
generate more efficient code than if you use some special functions, and can be
clearer than building the table programmatically.

For example:

func { a = { g(1), 2, 3 }, b = _.a[1] }

Currently you have to build the table bit by bit and then call the function:

local temp = { g(1), 2, 3 }
func { a = temp, b = temp[1] }

or in this case:

local temp = g(1)
func { a = { temp, 2, 3 }, b = temp }

which is a bit cumbersome either way.

To be consistent with the lexical scoping rules, the '_' has to reference the
innermost table being built, so we could allow something like '_._' to reference
a table two levels up, and so on:

func { b = g(1), a = { _._.b, 2, 3 } }


This example is rather trivial, but I've had real-life situations where it would
have been very useful to be able to build a table literal with various internal
references.


Hmmm... this is probably too ugly to gain general acceptance anyway!!

Andrew