The decisions made in introducing integers into Lua in version 5.3 need to be reconsidered.
+1 But I have another suggestion how this may be done.
Integers should be a fully distinct type
On the opposite, I suggest that there should be only one numeric type. The values "x=42" and "y=42.0" should be indistinguishable by any means provided by the language. Lua interpreter may choose any internal representations of a numeric value at any given time.
For example, number 42 may be stored as 64-bit integer, as float, as decimal string "42", as hex string "2A" or as arbitrary precision integer (I hope arbitrary long integers will be added to Lua someday).
Probably, it would be a good idea to be able to store more than one representation of the same value simultaneously.
Of course, some values do not have some representations: 1/0 and 0.5 are not representable as int64, ((1<<63)-1) is not representable as float.
Integers ... should not interoperate with floats.
IMO, it is more naturally to make any number interoperable with any other number.
But how should current integer-float interoperability problems then be solved in Lua?
The key idea of my suggestion is to make distinction between numeric operations.
So, for example, addition "+" should be replaced by two different operations:
1) normal addition (true mathematical addition on real numbers);
2) cyclic addition (addition modulo 2^64).
These operations should have different operation symbols, for example, "+" for normal and "[+]" for cyclic.
Or new syntax like "with cyclic arithmetic do ... end" should be used to explicitly choose the semantics of all numeric operations inside the block.
Normal addition should guarantee that internal representation is
safe (integer overflow must not happen if int64 is internally used).
Cyclic addition should convert both its arguments to int64 (or raise an error if you prefer strict policy).
Lua should decide in runtime which internal representation to give to the result.
The benefits of this approach:
1) Lua will be more user-friendly, we will return to old good days when Lua was simpler as it has only one numeric type;
2) The operation semantics will become clear from source code, troubles like "can this _expression_ silently produce undesired integer overflow?" will be gone away from Lua.
Please note that choosing the type of operation "c=a+b" vs "c=a[+]b" should have nothing to do with performance.
It is Lua interpreter's task to choose internal representation for faster execution. Lua user should think only about operation's semantics (according to the task user is working at).
