That's missing the entire point of the question. This isn't a suggestion that this would be a good idea for Lua to adopt. This is a question about if it's possible to use Lua's configuration options to make it able to integrate with other stuff that uses different representations for ints.
/s/ Adam
Yes, this "LuaJit trick" is really somehow very fascinating for Lua64,
or for Lua working only with float numbers (as Lua 5.1). But for int
supporting Lua, especially then Lua32, this would be quite
inacceptable I think. People who want int (and I think many people do,
especially in "small system" applications) really typically will need
full 32bit. ... In Lua64 maybe 32bit ints also would be fine ...
(maybe 40 bit for time applications, but 64 bit ints maybe not really
needed - so then some "dialect of LuaJit" could possibly work also in
Lua64 world with 32bit int support in some future, if somebody wants
to do this... LuaJit of course I think anyway will be only useful /
necessary for "large systems", and NOT for "small systems" which would
be the main target for Lua32).
On Mon, Aug 30, 2021 at 9:41 PM Coda Highland <chighland@gmail.com> wrote:
>
> On Sun, Aug 29, 2021 at 11:34 AM Flyer31 Test <flyer31@googlemail.com> wrote:
>>
>> ???There are no 63bit integers??? (or do you know a 63 bit processor?)
>
>
> There are a number of languages (OCaml comes to mind) that use a 32-bit or 64-bit tagged representation for values. Integers can be represented by using the most-significant bit to indicate that it's an integer type, and the rest of the bits contain the numeric value. This is analogous to how LuaJIT (and briefly, at one point in history, Lua itself) used NaN tagging to represent other types of values inside of an otherwise-standard 64-bit double-precision floating-point number.
>
> /s/ Adam
