Re: Ada to Ada Translator ?

[Optikos <optikos@verizon.net>]

On Wednesday, May 22, 2019 at 10:24:10 AM UTC-5, Shark8 wrote:
> On Wednesday, May 22, 2019 at 6:57:05 AM UTC-6, foo wong wrote:
> > 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... 

Spark8, please consider the following cascading ramifications.  Why do you think that the ARG has killed off nested subprograms, lambdas, and closures?

The implementation of named nested subprograms facilitates the implementation of unnamed nested subprograms (i.e., lambdas).  The implementation of lambdas facilitates the the implementation of closures.  Closures facilitate functional programming.  Functional programming facilitates correctness proofs.  Having another mechanism for Ada correctness proofs than SPARK facilitates the rise of a true competitor to GNAT+SPARK.  The rise of a true competitor to GNAT+SPARK facilitates the rise of a true direct competitor to AdaCore as a company.  Therefore, rewind:  nip named & unnamed nested subprograms in the bud.

Btw, this cascading-ramification sequence over in C++land could permit the rise of a C++ correctness prover (done all wobbly on shaky C foundations, but still it also could be at least •marketed• as a SPARK+GNAT competitor, even if it isn't as good).

> 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.

As much as I loathe their usage of the C++ template engine as a poor-man's functional programming language with atrocious syntax, Boost C++ libraries can serve as inspiration for how to implement lambdas and closures in the Ada-to-Ada code generator, especially in older Boost libraries targeting older C++ compilers that lack C++11-&-onward language support for lambdas and closures.

> > 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?

Patrick is proposing that his Ada-to-Ada code generator would accept all valid GNAT source code.  As such as GNAT-wrapper, it would need to at least parse & accept GNAT extensions so as to pass them through verbatim (and/or modified slightly if they interfere with the not-pass-through portions of the Ada-to-Ada code generator).

What would be really cool would be for the Ada-to-Ada code generator to accept Digital Ada's extensions too, especially a.app, which would permit multistage programming in a compile-time Ada interpreter as a rather direct competitor to MetaOCaml.