Re: For loops and closures

[RLake@...]

> These conditions are checked by `luaG_checkcode' when Lua loads binary
> files, so they cannot happen. But it is more difficult to check that
> some specific variables are not touched by other instructions during a
> loop. (To call setfenv with an incorrect argument is a C error; in C
> there are simpler ways to crash a program ;-)

OK, good points. I'll stick with the argument that adding and comparing
random bit patterns as though they were numbers is not going to do any
harm. :) To generate code that placed a non-numeric value into a for loop
variable would also be an error; the question is whether it could crash the
program or not, and I think the answer is "no" -- one could conceive of an
implementation of bignums in which numbers were, in fact, pointers, but it
is not clear to me that the Lua VM would actually support such an
implementation anyway, because of the fairly strong assumption that numbers
do not require garbage collection. It would be an interesting project,
though.

The issue about checking loops is an interesting one, though. Does
luaG_checkcode ensure the correct handling of OP_CLOSE? Does it matter if
an OP_CLOSE is "jumped" around? Perhaps not.

I got distracted by the thought of modifying the step value during a for
loop in order to implement "for brownian motion", but that's just plain
silly.

Anyway, this all just a quibble. The worst case is one extra store
instruction. To summarise:

1) It costs little or nothing, on balance, to make "for" index variables
fresh bindings in each iteration, both in table and numeric for statements.

2) There is no obvious application for the existing behaviour, whereas the
proposed behaviour is "expected" at least by some of us, and has obvious
application.

3) No conformant existing code will be broken by making this change.