Re: [ANN] Lua 5.4.0 (work2) now available

[Sean Conner <sean@...>]

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
> 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). 

  Could you point out in the relevant standatds for Java and Javascript
where it says this?  I can accept it for Java, but I'm dubious about
Javascript, which uses floating point as the basis for all numeric
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
same.

> 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...): 

  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
> 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)

  I'm not sure what you mean.  I have myself written a computer emulator in
both C and Lua [1] and both work the same [2].  

  -spc (What next?  That C needs fixing to emulate Javascript?)

[1]	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.

[2]	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
	same results.