Ada to webassembly

Ada to webassembly

[mockturtle]

Dear.all,  :-)
I remember several months ago someone was petting with the idea of having a backend for WebAssembly.  To be honest, I like the idea of abandoning JavaScript (ugh! Gross... Go wash your keyboard with soap! :-))  for Ada in web development (although I do not do web development...)

I am curious about the current status of this idea. Is someone working on it?  


I searched in the group for "WebAssembly," but I found only one post that suggested  Ada->C->webassembly.  

Re: Ada to webassembly

[alby.gamper]

On Tuesday, May 7, 2019 at 8:12:01 PM UTC+10, mockturtle wrote:
> Dear.all,  :-)
> I remember several months ago someone was petting with the idea of having a backend for WebAssembly.  To be honest, I like the idea of abandoning JavaScript (ugh! Gross... Go wash your keyboard with soap! :-))  for Ada in web development (although I do not do web development...)
> 
> I am curious about the current status of this idea. Is someone working on it?  
> 
> 
> I searched in the group for "WebAssembly," but I found only one post that suggested  Ada->C->webassembly.

Hi

I believe that the LLVM backend does support webassembly (to what extent, I
don't know). So until LLVM has a front end to Ada, then the above approach,
ie Ada -> C -> webassembly could possible be an alternative ?

Alex

Re: Ada to webassembly

[Optikos]

On Wednesday, May 8, 2019 at 4:46:20 AM UTC-5, alby....@gmail.com wrote:
> On Tuesday, May 7, 2019 at 8:12:01 PM UTC+10, mockturtle wrote:
> > Dear.all,  :-)
> > I remember several months ago someone was petting with the idea of having a backend for WebAssembly.  To be honest, I like the idea of abandoning JavaScript (ugh! Gross... Go wash your keyboard with soap! :-))  for Ada in web development (although I do not do web development...)
> > 
> > I am curious about the current status of this idea. Is someone working on it?  
> > 
> > 
> > I searched in the group for "WebAssembly," but I found only one post that suggested  Ada->C->webassembly.
> 
> Hi
> 
> I believe that the LLVM backend does support webassembly (to what extent, I
> don't know). So until LLVM has a front end to Ada, then the above approach,
> ie Ada -> C -> webassembly could possible be an alternative ?
> 
> Alex

Although unstated, as the only currently-available open-source Ada compiler, GNAT might be the most likely candidate Ada compiler to modified to emit C (or C++) from its GENERIC/GIMPLE layer.  (GNAT's Ada semantically-adorned abstract syntax tree [AST] is tree transduced to an analogous semantically-adorned C/C++ AST which is then usually fed into GCC's RTL/machine-language backend but conceivably a C representation of the GENERIC/GIMPLE semantically-adored C/C++ AST could be read out in the middle-layer-to-upper-layer direction, reversing the usual downward flow.)  The burning question is:  would FSF & allied legal-defense parties and/or AdaCore consider C to be RLE's Target Code (i.e., the antithesis of an intermediate representation) in the case of
GNAT -> C -> LLVM -> WebAssembly because the C was read-out (as a derivative work) from the semantically-adorned C/C++ AST that itself clearly & undeniably an intermediate representation?  Or would the generated C source code read out from the GENERIC/GIMPLE layer be an intermediate representation due to not achieving Target Code status?  GPLv3's RLE carves out Target Code as a safe harbor.  GPLv3's RLE crashes to pure GPLv3 if Target-Code status is not achieved by persistently-emitted files/bytestreams from GCC.

(Note I am using the term “intermediate representation” here in its generic technical usage as a mere noun, not as LLVM-IR proper noun.  Hence, I am avoiding abbreviating intermediate representation as IR.)

https://www.gnu.org/licenses/gcc-exception-3.1-faq.html

The answer to this question is crucial because a Compilation Process that emits any representation of modern GPLv3 GNAT's Ada semantically-adorned AST other than Target Code (e.g., assembly language;  machine code; JVM bytecode) is deemed an intermediate representation that ruins the criteria for “Eligible”.  Once the criteria for Eligible is ruined, the Compilation Process cannot graduate to the level of Eligible Compilation Process.  Once a Compilation Process has failed to achieve Eligible Compilation Process status, then the Target Code emitted by the mere Compilation Process is forcibly GPLv3 without the Runtime Library Exception, as per the following quotation:

as quoted from the WWWpage at the URL above:
“In order to take advantage of this permission, the Compilation Process that you use to create Target Code has to be “Eligible,” which means that it does not involve both GCC and GPL-incompatible software. It's important to remember that the Compilation Process starts when you feed any high-level code to GCC, and ends as soon as it generates anything that can be considered Target Code. Because of that, •••as long as GCC isn't writing out intermediate representation•••, your Compilation Process can still be Eligible even if you use GCC in conjunction with GPL-incompatible assemblers, linkers, or high-level source generators: those programs aren't involved in the Compilation Process as it's defined here. The only place you can't use GPL-incompatible software with GCC is when it's performing the core compilation work.  ¶  However, if you used GCC in conjunction with GPL-incompatible software during the process of transforming high-level code to low-level code, that would not be an Eligible Compilation Process. This would happen if, for example, you used GCC with a proprietary plugin.  ¶  As long as you use an Eligible Compilation Process, then you have permission to take the Target Code that GCC generates and propagate it ‘under terms of your choice.’  ¶  If you did use GPL-incompatible software in conjunction with GCC during the Compilation Process, you would not be able to take advantage of this permission. Since all of the object code that GCC generates is derived from these GPLed libraries, that means you would be required to follow the terms of the GPL when propagating any of that object code. You could not use GCC to develop your own GPL-incompatible software.”

Therefore, under one apparently-plausible legal interpretation of the plain-language meaning of the agreement's terms under the body of (Texas) contract law, it seems that GNAT -> C -> LLVM -> WebAssembly could easily be strictly GPLv3 without the benefit of the crashed-&-burned RLE's “under terms of your choice” licensing generosity to which most GNAT users are accostumed.  This hardline GPLv3-only licensing of executables for WebAssembly might be surprising and/or intolerable to some users who seek to distribute their WebAssembly derivative works under a non-GPLv3 license.

Conversely, porting LLVM's BSD-licensed WebAssembly code generation as output from GCC's RTL (i.e., all within GNAT without any intermediate representations squirting out of GNAT to files or shared memory) would not evoke any of those legal complications above, because WebAssembly downstream from RTL is much more clearly fully achieving the Target-Code status, much the same as JVM bytecode does.

GPLv3's RLE informs what the likely legally-most-proper software architecture should be for
GNAT Ada AST -> GENERIC/GIMPLE -> RTL -> port of LLVM's WebAssembly to GCC.