[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: [Proposal] Table literal indexing (Was: Re: [Proposal] .name global indexing (Was: Re: 'with' statement))
- From: Andrew Cannon <ajc@...>
- Date: Tue, 15 Mar 2016 20:09:23 +0100
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
- References:
- 'with' statement, Dirk Laurie
- Re: 'with' statement, Roberto Ierusalimschy
- Re: 'with' statement, Rena
- RE: 'with' statement, Thijs Schreijer
- [Proposal] .name global indexing (Was: Re: 'with' statement), Soni L.
- Re: [Proposal] .name global indexing (Was: Re: 'with' statement), Coda Highland
- Re: [Proposal] .name global indexing (Was: Re: 'with' statement), Dirk Laurie
- Re: [Proposal] .name global indexing (Was: Re: 'with' statement), Andrew Cannon
- Re: [Proposal] .name global indexing (Was: Re: 'with' statement), Rena
- Re: [Proposal] .name global indexing (Was: Re: 'with' statement), Andrew
- Re: [Proposal] .name global indexing (Was: Re: 'with' statement), Alloyed