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.
As I said, this depends if the "C" environment is available, and this is not the case for all Lua environments where there's NO access at all to it (blocked completely by security restrictions: and this is the goal of WebAssembly to avoid this barrier by emulating a stable and predictable environment in which all limits are known).
Even if it's available, your Lua program will depend on the implementation and limits of numbers inb this C environment, making it then difficult to support WebAssembly reliably and portably, without first fixing the C environment (which is notoriously difficult to make portable for its partially defined and too permissive datatype system):
You need the modern support of "stdtype" (initially from the ANSI standard, or at least C99 and later) defining basic native types more strictly than what basic C types provide.
I know that most modern C environments now have this "stdtype" library; but using it (and only it) has a known performance cost, and it requires discipline of C programmers (i.e. not using the "int" datatype at all, and not even "char", "float" and "double" without an overlay reimplementing if needed the standard types and the standard artithmetic and mathemetic operations); or it requires a C compiler that will enforce these limits using a more precise set of limits for all basic C types (char, short, int, long, long long, and their signed/unsigned variants, plus bool, float and double) and defining stricter semantics for or for evaluation order and allowed "aliasings" caused by pointers and references, as well as exception handlers (this may also require using specific versions of the standard C library compiled with these stricter rules).
