Re: Ada to Ada Translator ?

[Shark8 <onewingedshark@gmail.com>]

On Wednesday, May 22, 2019 at 6:57:05 AM UTC-6, foo wong wrote:
> Unfortunately, this seems like a typical thread here. Lots of bickering and a lot theory. Very little co-operation or offers to join in to help.
Yes, this is indeed the case in a lot of these discussions, even when the topic is interesting — and one of the reasons I want to do Byron [MIT licensed] is to just get the hell away from all the GPL bullcrap that's so unproductive.

Another reason is to have a free compiler with no entanglements with C. I don't want dependency on clib or anything else for the compiler... that just seems utterly counterproductive from either the security or correctness/provability standpoints.

> First and foremost, I wanted to bring an idea to the Ada community that might help others. I have very little time to program and I would love it if Ada was not tied so tightly to a company that is not helping it to succeed.
I completely understand, and agree with you here — while AdaCore does a lot, it's rather obvious that they aren't interested in moving/marketing Ada outside fairly restricted niches, and I suspect that having alternate & affordable alternatives to GNAT would go a long way to break that mentality.

For Ada/Ada translation, perhaps the most interesting would be some manner of back-porting the new features to old Ada — I imagine being able to compile your Ada2020 down to Ada83 (say for DEC's Ada compiler) would be a *huge* boon to the community — the real question here would be how to integrate the new-features into the generated-code and there are three realizations that I can envision off the top of my head. (1) Generate library/object code + the spec-files to interface with them; (2) Fully generate the execution-code, including things like predicate-checks, explicitly; and (3) Generate the files, but reducing the explicit execution-code as much as possible into a library that is either externally linked or explicit machine-code insertions.

> There are so many brilliant people here, if you guys worked together, Ada would not have to be in this state. Randy's posts are helpful in that now I know that Yacc/Flex is enough to build a compiler and I am not even proposing a compiler but rather an Ada to Ada source translator.
To have as useful a translator as possible your proposed translator would have to understand the underlying semantics of the GNAT extensions and the equivalent in standard-Ada, which might not exist, and so would have to have something similar to the above conceptual Ada2020-to-Ada83 compiler.

> All libraries are written in Ada. Just to stick with the topic I brought up earlier, if nested subprograms were translated into more primitive Ada code, then the translator would translate any library code. The only grammar that is required is for core Ada.
What is the use-case of the "nested subprograms" example? I just don't get it... plus, capturing the context of those subprograms might be a bit more complex than you're thinking: if they use local variables, the the realization might be better as a GENERIC subprogram with those very objects as formal parameters.

> Also I would like to mention that the worst thing that Adacore is doing is withholding new targets. They bought up Ada vendors that had support for various targets but they did not merge this into GNAT FSF. Now there is support for ARM but there could have been long ago but the ARM support is coming with strings attached.
Second-worst; the elimination of DOTNET and JVM targets is really irksome. (And it seems like the long-shot of getting MS to make an Ada-implementation for DOTNET is actually more likely than AdaCore updating their DOTNET implementation.)

> I am going to receive a severe mailing list beating for saying this but it seems to me that Adacore has lead FLOSS Ada to a point where it is a fish out of water.
Why would you get a beating for this?
It's fairly obvious: there are tons of other languages, even those with corporate sponsors [eg Go, Rust], that don't beat the GPL licensing horse. — There are languages that *don't* stir up fear, uncertainty, and doubt with potentially expensive legal processes and thus drive away small/medium businesses.

> It's great that it is being used for games and web servers and such but Ada has gills and fins, it's supposed to be in the water.
> 
> This is not what it was designed to do. It's supposed to be used to control missiles and tanks and could be used for non-military purposes as spin-off. Ada 95 added OO and there there is a ton of stuff like interfaces and whatnot but is any of this needed to fire off a tank shell or missile?
Ada was designed for this, yes; but it was *ALSO* designed to be a GENERAL PURPOSE programming language to replace the literally HUNDREDS of languages being used by the DOD. — It did so, reducing the number of languages in-use by an order of magnitude.

> Where is the target support!
> 
> I personally don't want to create weapons rather scientific instruments.
I'm involved in Astronomy right now, Ada is perfectly suitable for the tasks here; in fact, a *LOT* of complexity could be reduced if we were to have a single, distributed Ada program doing all of our command-and-control as well as data-production. — We could probably reduce the 25-30 computers in-use for data-acquisition/operations to perhaps 8, have a single code-base, and more assurance with respect to scheduling, maintenance, data-correctness, and implementation-correctness.

> Based on this website:
> https://wiki.osdev.org/Ada_Bare_bones
> 
> These are the parts that the translator would need to translate into more primitive Ada code:
> 
> """
> 
> pragma Discard_Names;
> pragma Restrictions (No_Enumeration_Maps);
> pragma Normalize_Scalars;
> pragma Restrictions (No_Exception_Propagation);
> pragma Restrictions (No_Finalization);
> pragma Restrictions (No_Tasking);
> pragma Restrictions (No_Protected_Types);
> pragma Restrictions (No_Delay);
> pragma Restrictions (No_Recursion);
> pragma Restrictions (No_Allocators);
> pragma Restrictions (No_Dispatch);
> pragma Restrictions (No_Implicit_Dynamic_Code);
> pragma Restrictions (No_Secondary_Stack);
> """
> 
> but even some of these could be skipped over. If I am the one that ends up doing this, I will only be focused on hardware embedded Ada and I will focus on new targets and not every last corner-case feature
??

Forgive me, but I don't see how these restriction pragmas dovetail into an Ada-Ada translator... at all. Could you explain how you see them doing so?