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

[William Ahern <william@...>]

On Fri, Nov 16, 2018 at 11:49:56PM +0100, Philippe Verdy wrote:
> Le ven. 16 nov. 2018 à 22:38, Sean Conner <sean@conman.org> a écrit :
<snip>
> >   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).
> >
> 
> You're repeating exactly what I said: this is not defined formally in Lua,
> but by the implementation (for *example*, what C gives, but C is not a
> requirement of the language for implementing it).
> 
<snip>
> >   If WebAssembly can run Linux, then it certainly can run Lua, since it's
> > written in C, much like Linux.
> >
> 
> You consider the exact reverse problem: yes, WebAssembly can certinaly run
> Lua, but I doubt that Lua can safely (and portably) run WebAssembly this is
> what I wrote) without breaking, except with specific implemantations of Lua.

The ease of implementing WebAssembly in Lua would be little different than
implementing it in C on the same platform. If the native C environment used
IEEE 64-bit doubles then that makes implementing WebAssemly semantics easy
in both C and a stock Lua build. If it doesn't then it will be more
difficult in either case. (Even if you can utilize _Float64 in C you still
need to deal with promotion and similar headaches that require careful
treatment.)

And don't forget, WebAssembly doesn't provide 64-bit integers so
implementing Lua (>= 5.3) arithemtic directly in WebAssembly necessarily
requires synthesizing the type. Also, WebAssembly doesn't provide a goto
construct, so implementing continuation-like patterns (e.g. jump tables) is
a headache. Compiling Go to WebAssembly requires horribly inefficient hacks
for this reason (see
https://docs.google.com/document/d/131vjr4DH6JFnb-blm_uRdaC0_Nv3OUwjEY5qVCxCup4/preview#).
By contrast, Lua 5.2 added goto precisely for the convenience of code
generators.

The fact that you can surely compile PUC Lua's C source to WebAssembly using
existing C compilers that target WebAssembly can't be compared to the ease
of hosting WebAssembly directly in Lua. The fair comparison would be
compiling a C-based WebAssembly VM to Emscripten-like Lua code using a
preexisting toolchain. In which case all these points are moot as they'd
already be solved in *both* directions.