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".
One "bad" thing about Lua, is that the value range and precision of Lua "numbers" is not strictly defined (this is the same problem as for "int", "flaot" and "double" datatypes in C/C++, which are implementation dependant: that's why POSIC defined a standard library of common constrained numeric types), so there's a portability problem. Such thing does not happen in Java and _javascript_ where numeric datatypes are strictly defined (except that in Java, _javascript_, C, C++ and even Lua, there's still varability about "strict" computing modes and rounding modes which can be tweaked locally, by some hints, which are not always mandatory... except in Java and Javascrip,t where "strict" numeric evaluation is enforcable by the language itself). Lua also does not formally define the allowed values for infinites, Nans, denormals, or sign-ness of zeroes
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.
This has a consequence: it's not so simple to emulate in Lua an other environment like it is possible in Java or _javascript_ (e.g. with WebAssembly which allows runninig a full Linux OS inside a 100% pure _javascript_ program...): you need to specify the supported platforms (i.e. specific instances of Lua, i.e. the set of supported Lua VMs).
I bet that Lua will later defined such standard library, at which time it will be able to compete with _javascript_, and will effectively be able to really implement _javascript_ itself in a Lua program, or implement other languages like Python, PHP, C/C++ and various kinds of "emulators") and it will easier to port programs so that they'll run unchanged on other architectures (making use of GPUs/APUs/VPUs or working over a computing grid over a network with Lua objects distributed in various hosts, but Lua will need other concepts, notably "security contexts" like in Java, or in web protocols, or those standardized now in ECMAScript for _javascript_)
