Re: Long chains of objects (aka tables)

[Jay Carlson <nop@...>]

Roberto's "(t or Empty_Table)" produces better code than iteratively setting a local. I was so focused on avoiding parentheses in the surface syntax I did not think about it, even in a macro expansion where nobody cares about parens.

Defensively, I'd probably make E raise an error on attempts to write to it.

On May 17, 2014, at 1:58 PM, Thiago L. <fakedme@gmail.com> wrote:

> On 17/05/2014 14:34, Petite Abeille wrote:
>> On May 17, 2014, at 7:07 PM, Thiago L. <fakedme@gmail.com> wrote:
>> 
>>> I want something like |local v = t?t1?t2?t3|... (actually I want |local v = t?.t1?.t2?.t3|…)
>> Why don’t you simply write a little function that does exactly that then?
>> 
>> v = get( t, ‘1.2.3.4.5.6.7.8.9’ )
>> 
> And what if I want to do something like table?something[someVariable]?somethingElse

This is a real problem for string-based little-languages because someVariable isn't necessarily visible. A common answer is

    {"$table?something[$someVariable]?somethingElse", 
        table=table, someVariable=someVariable}

and the reason you can't have $ as an operator is my macro syntax for that list constructor:

    $[[ $table?something[$someVariable]?somethingElse ]]

which permits the usual Lua function call shorthand of

    get$[[ $table?something[$someVariable]?somethingElse ]]

I know this is the second time in a month I've mentioned it, but it shows up every time we take the string escape hatch for metaprogramming.

Anyway $"" creates garbage on each pass; it should be avoidable with syntax like get:$[[ $table ]] => get([[ $table ]], table) but I didn't ever test that enough. It also requires the compiler and the receiver be in perfect agreement on what variables there are, and what order to send them in.

Jay