RE: confusion about an exercise in programming lua 3rd

Indeed – the explanation becomes much clearer if you replace the ‘a.a’ which is frankly confusing with

a = {}

a.thistable = a

now the original table that we’ve called a contains a reference to itself, stored in the entry ‘thistable’.

It is a lot simpler to then understand that

a.thistable.thistable.thistable

is exactly the same as a.thistable

If you then wrote:

a.thistable = 3

It’s clearly replacing the ‘thistable’ entry with the number ‘3’. So similarly

a.thistable.thistable.thistable = 3

Does exactly the same thing.

The fact they’ve chosen to make the example a little more confusing by awarding the table entry the same name as the global variable doesn’t help (and is a little unnecessary for getting the point across).

-Chris

From: lua-l-bounces@lists.lua.org [mailto:lua-l-bounces@lists.lua.org] On Behalf Of Axel Kittenberger
Sent: 25 November 2014 15:08
To: Lua mailing list
Subject: Re: confusion about an exercise in programming lua 3rd

This is exactly one of the reasons why a few years ago I switched in my projects to work with immutable types only and simulate immutables with languages that don't have them natively.

Cycles? Do not happen. Point. Brain damage avoided.

It is a nice exercise about understanding the principles, but for any real project, just don't do this kind of back-cycles unless you that surreal case, which somebody now sure comes up to counter me, in which you really need it. I say, one can even work around that surreal case.

PS: As other tried to explain already, all a[.a]* point to the same table. Thus you are always altering the original table and breaking the cycle with it.

On Tue, Nov 25, 2014 at 2:39 PM, Thomas Jericke <tjericke@indel.ch> wrote:

On 11/25/2014 01:57 PM, Kang Hu wrote:

In Programming in Lua, Third Edition:

Exercise 2.6: Assume the following code:

a = {};

a.a = a

1. What would be the value of a.a.a.a ? Is any a in that sequence somehow

different from the others?

2. Now, add the next line to the previous code:

a.a.a.a = 3

What would be the value of a.a.a.a now?

my reasoning is

1. a.a.a.a = ((a.a).a).a = (a.a).a = a.a = a

2. with the the previous reasoning, 'a' should be 3.

    but actually, 'a.a' equals 3 and 'a' is a table.

why?

Your mistake is that you disregard that tables are stored as reference in Lua.

a = {}; does not mean that a is the empty table but that a is a reference to an empty table.
a.a = a means that a.a becomes a copy of the reference to that same table.

If you make a similar code in C you would write:
table* a = create_table();
a->set("a", a);

table* aa = a->get("a");

Now that mean that aa != a but *aa == *a
aa and have not the same value but reference the same value.

Now when you reasign a variable in Lua that stores a reference, you don't change the value it points to, but the value of the reference itself:
a.a.a.a = 3
equals to this C code
table* aaa = a->get("a")->get("a)->get("a);
aaa->Set("a", 3);

In the last line, the field a of the table is set to 3, but the original pointer to the table is not touched.

It is important to see that in my C code, there are 3 get calls and one set call.
The statement a.a.a.a = 3 is equivalent to a.get("a).get("a").get("a).set("a", 3), in Lua the last dot of a left hand side _expression_ has a different semantic than the other ones.
This can easily be proven by printing out the calls to __index and __newindex when using a metatable.

--
Thomas