lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Actually whether an OCaml reimplementation of the language (not the C
API obviously) would still count as Lua.

It's kinda uncomfortable that such a seemingly simple question would
lead to so much flaming and insulting other languages' technical
choices. Almost feels like going elsewhere and never following up on
here would've been a more appropriate response from us. :/

On 2021-08-31 9:03 a.m., Coda Highland wrote:
> 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
> On Tue, Aug 31, 2021, 5:19 AM Flyer31 Test <
> <>> wrote:
>     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 <
>     <>> wrote:
>     >
>     > On Sun, Aug 29, 2021 at 11:34 AM Flyer31 Test
>     < <>> 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