lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On 28.07.2016 20:37, Tim Hill wrote:

On Jul 28, 2016, at 4:56 AM, Thomas Jericke <tjericke@indel.ch> wrote:

On 28.07.2016 13:37, Dirk Laurie wrote:
2016-07-28 12:47 GMT+02:00 Thomas Jericke <tjericke@indel.ch>:

From the top of my head this is the most explicit statement. 

"Lua supports coroutines, also called collaborative multithreading. A coroutine in Lua represents an independent thread of execution. Unlike threads in multithread systems, however, a coroutine only suspends its execution by explicitly calling a yield function."

As you see in my example (that you cut from the quote), there is no yield in it. So the programmer rightfully can expect that the function is run uninterrupted.

Come now. As an imperative language, it is safe to assume that Lua will execute statements in the order listed. That is:

a; b
c

Will execute in the order a, b, c with each statement completed before the next begins. However, the order of execution within a statements is explicitly not guaranteed:

a = b() + c()

Could call b() first or c() first. Similarly, table constructor expressions may be evaluated in any order (as can an _expression_ list). There are good reasons for not specifying this order, as on some architectures it is easier to do things in one order rather than another.

Specifying that ‘#’ assignments are special just makes things messier:

a = {1, #, 2, 3}

I don’t think many people would intuitively expect # to be 3 in this case.

—Tim


Totally agree. But while I was trying to sleep I found out that the order of execution doesn't matter at all for the simple list constructor style like { 1, #, 2, 3}.
Why? Because the value of # is already known at compile time, and the parser therefore can easily compute the length of the array already.
This is of course not true for the statement { [a] = 1, [b] = 2, [#] = # }, here you have no chance to calculate the array length at compile time unless
you are really, really sure what the values of a and b are at runtime. (So never if you consider the debug library).

Anyway I am currently think {(1, 2, 3)} is the more intuitive array constructor syntax. This because (1, 2, 3) is already the syntax for an argument list.
To me {(1, 2, 3)} reads like: I have this list here that you should back me into a table please.
--
Thomas