[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] Lua 5.4.0 (work2) now available
- From: Sean Conner <sean@...>
- Date: Fri, 16 Nov 2018 16:37:48 -0500
It was thus said that the Great Philippe Verdy once stated:
> 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
> 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).
where it says this? I can accept it for Java, but I'm dubious about
operations (like Lua 5.2 and earlier).
> Lua also does not formally define the
> allowed values for infinites, Nans, denormals, or sign-ness of zeroes
Um ... what? IEEE-754 (which is what most modern floating point is based
on) does define infinities (two, positive and negative), NaNs (only to say
there are two types---quiet and signaling; it says nothing else about then
except that NaN != NaN), supports denormals and gives two zeros (0 and -0).
If you mean for Lua to state "must support IEEE-754" then say so. But Lua
is based upon what C gives, and what C gives is not IEEE-754 (or at least,
does not mandate its use).
> 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.
I have not noticed any differences between PUC Lua (5.1) and LuaJIT. I
have also not noticed any differences between x86-32 bit version of PUC Lua,
x86-64 bit version of PUC Lua, SPARC 32-bit version of PUC Lua, and SPARC
64-bit version of PUC Lua. All have behaved (and current, are behaving) the
> This has a consequence: it's not so simple to emulate in Lua an other
> WebAssembly which allows runninig a full Linux OS inside a 100% pure
If WebAssembly can run Linux, then it certainly can run Lua, since it's
written in C, much like Linux.
> 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
> 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
I'm not sure what you mean. I have myself written a computer emulator in
both C and Lua  and both work the same .
 Based around the Motorola 6809. I also emulate the 6840 (timer
chip), 6850 (ACIA chip), 6843 (floppy controller) and 6855 (DMA
controller). Mostly for my own amusement.
And yes, I have two versions, one in C, one in Lua.
 Nearly the same---the interface is much nicer on the Lua version as
it's easier to manage than in C. But the emulation works
identically, as I can run the same 6809 program on both and get the