the loop variable is neither an "integer" or a "float", it is just a Lua "number".
When you "print" the number, it may display ".0" decimals or not, which makes you think that there's a difference, but the actual number is the same. There's no segregation of types (such segregation isonly done internally by the implementation of the VM which may infer some better datatypes, if it correctly checks the value range and needed precision).
In a "numeric for loop", it's true that the control variable may be internally compiled as an integer, but only if:
- the start and limit values are integers (no decimals)
- the start and end values fall into the value range of integers
- the needed precision allows storing the difference between each step from start to end values (i.e. start + step > start and end - step < end, when these expressions are computed in the chosen "integer" datatype)
Otherwise the control varaible will still need to be able to represent the whole range and precision of Lua "numbers" (i.e. a 32-float or double, depening on which datatype the impelmentation uses, but most Lua implementations should use a 64-bit IEEE double precision number to represent Lua "numbers".
I would really suggest that Lua is extended to define a standard library of strictly defined numeric types (strict value ranges and precision, strict evaluation, rounding modes) to allow creating portable programs (even if this is at the price of speed). Lua for now is (like C/C++) tweaked in favor of performance, not necessarily portability (and semantics): each implementation then defines its own instance of the language, they are not really /stricto sensu/ the same language if each instance has its own limits. Unfortunately there's no simple way for a Lua program to safely detect these limits.