Re: Numeric for loop: Changing control variable REALLY dangerous?

[Gerhard Sittig <gerhard.sittig@...>]

On Sat, 2022-12-10 at 02:47 -0500, Sean Conner wrote:
>
> It was thus said that the Great bil til once stated:
> > In chapter 3.3.5, there is a bit a "strange sounding" warning:
> > "You should not change the value of the control variable during the loop."
> >
> > ... is this not a bit "over-cautious"?
> >
> > e. g. in a typical loop "for i=1,count do ... end", it is quite often
> > really useful to repeat a loop sequence by "i=i-1", or to repeat
> > complete loop by "i=1" assignment.
> >
> > This REALLY can be dangerous? (or can give anybody possibly give some
> > illegal / "bad-running" example for such change?)
>
>   I tried it, in Lua 5.1, 5.2, 5.3, 5,4 and LuaJIT 2.0:
> [ ... ]

You might have run that on "popular" hardware, with the
"reference" implementation, on a single platform, etc etc. (Past
communication strongly suggests that you are aware of this topic,
just stating here for the record.)

The point is that whatever an arbitrary implementation happens to
"give" you (what you can observe) need not be backed by the
standard. Any implementation, including future or past versions
of the same implementation that you observed, as well as other
configurations of that same version of the same implementation,
are free to behave differently. And this is absolutely OK as long
as they don't violate the standard.

Manipulating the content of complex data while you traverse it is
easily seen as complicated (think hashed dictionaries and
changing their hashes while you enumerate them). "Simple" numeric
loops may not need to suffer from that constraint at first
glance. But also could. The compiler or the execution might map
the loop to machine code that would not let you "affect" the
control variable during execution. Some target architectures have
"decrement and jump", others even use shadow registers or other
things that "are not variables" to implement counted loops. Most
could involve caching or deferred execution, and changing things
that already got evaluated, may not result in the loop behaviour
that you expect.

As others have stated: Don't use the counted loop if you cannot
foretell how many iterations you need to execute, or what their
loop index would be. If you have a termination condition that
keeps changing while you execute the loop, then use instructions
which support this semantics.

>   I suspect the warning is there because changing the control variable
> doesn't work as one might expect, and not to rely upon changing either the
> control variable, or the limit variable.

That is exactly how I read the standard. Avoid wrong
expectations, that only "happened to work" by coincidence,
leaving developers unaware of their creating non-portable code.
Piling up code that does not necessarily do what authors intended
is NotAGoodIdea(TM).


virtually yours
Gerhard Sittig
--
     If you don't understand or are scared by any of the above
             ask your parents or an adult to help you.