[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] Lua 5.4.0 (work2) now available
- From: William Ahern <william@...>
- Date: Fri, 16 Nov 2018 15:46:51 -0800
On Fri, Nov 16, 2018 at 11:49:56PM +0100, Philippe Verdy wrote:
> Le ven. 16 nov. 2018 à 22:38, Sean Conner <email@example.com> a écrit :
> > 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).
> > 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
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
By contrast, Lua 5.2 added goto precisely for the convenience of code
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.