lua-users home
lua-l archive

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


What is even worse is that the same page states that " Second, the control variable is a local variable automatically declared by the for statement and is visible only inside the loop".
Which means that the local variable (visible inside the loop) and the control variable (for the loop itself, which should be completely hidden in the iterator, so that the local variable in the loop only gets a *copy* of the value in the hidden control variable of the iterator) are confused in that statement as if they were the same (which is an error in my opinion).

I don't know which approach is valid, the doc is clearly ambiguous.

The behavior should be specified clearly in the doc by showing, like in my example:
  for x=1,3 do x = x+0.5; print(x, ' ') end
that it MUST print "1.5 2.5 3.5", and NOT "1.5 3".

This stateless approach will then clearly ease the implementation of all compilers and interpreters, with predictable results, and no need to track in the source code of the inner loop if a "control variable" is assigned (this should have no effect at all on the number of loops executed, so that the number of loops is fully predictable before the first loop starts, and only the "break" instruction can interrupt the loops before the iterator reaches the ending condition).

As long as this behavior is unspecified, a compiler should emit a strong warning, if ever it finds inside the loop an assignment to the "local variable" declared by the "for" statement, which is not necessarily the control variable of the hidden iterator.

I'm not sure that there's really an iterator object instantiated to contain the control variable, the maximum value to compare with the control variable, and the stepping value; the doc just indicates that there are two hidden variables for the end value and the stepping value, and a compiler may also want to avoid creating a real iterator object, and would prefer just generating 1 hidden variables (or 2 with the stepping value), leaving the control variable directly usable as the local variable of the loop). With the stateless approach, a compiler would need to generate 2 hidden variables (or 3 with the stepping value) separately from the local variable visible inside the loop code).

When the stepping value is negative, the completion test is reversed: the "end value" is a minimal value so the condition is "while __control__>= __end__ do..." instead of ""while __control__<= __end__ do...", so there are actually two kinds of numeric iterators generated (forward or backward).

The doc is not clear about the behavior of a numeric for loop, when the optional stepping value is zero: "for i=1,10,0 do...end" cannot be determined to be a forward or backward iterator, but logically this is an infinite loop, given that the values in the two first parameters (1,10) are both inclusive.

Le jeu. 15 nov. 2018 à 17:03, Philippe Verdy <verdy_p@wanadoo.fr> a écrit :
Not all, according to the Lua doc in section 4.3.4 (Numeric for), the behavior is unspecified. I bet that the interpreter mode uses the 2nd approach which is simpler, but may give different results.
This is stated at end of this page:
https://www.lua.org/pil/4.3.4.html

Le jeu. 15 nov. 2018 à 14:46, Albert Chan <albertmcchan@yahoo.com> a écrit :
On Nov 15, 2018, at 8:23 AM, Philippe Verdy <verdy_p@wanadoo.fr> wrote:

> My opinion is that Lua should have been defined so that only the first (stateless) behavior is valid, and so "for x=(a),(b) do (...) end" should always behave like "for x in foriter(a, b) do (...) end"

Does any version of Lua *not* do this way ?