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

[Francisco Olarte <folarte@...>]

On Mon, 12 Dec 2022 at 06:16, bil til <biltil52@gmail.com> wrote:
> Am So., 11. Dez. 2022 um 12:33 Uhr schrieb Rolf Kalbermatter
> <rolf.kalbermatter@kalbermatter.nl>:
> > It’s not bizarre at all. Lua may be not a compiler in itself (although there exist JIT versions
> > and similar of it) but it’s written in C. And C has the notorious feature of stating many things
> > as not being defined for the sake of efficient implementations on all kind of hardware, including
> > very esoteric ones.

I was tempted to reply to that yesterday, will do it know. Lua IS a
compiler, like Java, Perl or Python, it just does not compile to real
mchine code, but to a virtual machine.

The fact that the compiler AND the VM are written in C is not too
problematic, Lua team does normally a good job avoiding undefined and
implemetation defined behaviour.


> I have to admit, that I have not any overview how Lua does the for
> looping in detail, but I would bet that the for looping in Lua FOR
> SURE does NOT rely on any "C Compiler for looping approach". It
> typically just should be programmed very similar to the Lua while do
> end / repeat until loop, just with this additional counter variable,
> which MUST be a "normal Lua" value, so it must reside on Lua stack
> "very Lua normally".

Doing loops the C way ( with a var and a while ) is not the usual way.
It may be done that way if it is appropriate. But i.e. lot of
languages precompile a counted for loop with non integer ( or even
non-one, it depends on your CPU power ) with constant limits to a
counted integer loop on an inaccessible counte plus a running
increment of the loop variable.

But hey, if you want to test the limits of what you can do, go ahead.
But this is not just implementation-defined, it is more on the
undefined behaviour field, so be prepared to have your code blown in
x.y.z because they found a better way to do it. And they do, loops is
one of the things changing lately.

If you want C semantics, just stick an extra do-end for scope and use
a while, some lines more is cheap for the guaranteed behaviour.



> After the comments above of Francisco, I interprete it as safe to
> interprete the warning in the reference manual more like "It is safe
> to vary the counter loop variable inside the for loop limits, but any
> new value outside the for loop might lead to undefined behaviour." ...
> I hope I will survive this and not run into explosions :).

I do not know if you are referring to me, and if you are how my
comments can have lead you in that direction.

In a language with built in counted loop, unless otherwise specified
by the language, what people normally do is "index variable is read
only inside the loop" and "index variable does not exist under the
loop" ( so you can not use the VARIABLE outside, it does not exist,
but you can use the NAME if you have it bound to something ). Which is
more or less THE OPPOSITE of what I interpret from that paragraph.

Francisco Oalrte.