Re: Your wish list for Ada 202X

["Dan'l Miller" <optikos@verizon.net>]

2014/04/29 09:26 Tero Koskinen:
> 26.3.2014 23:06, Randy Brukardt wrote: 
> > Commenting here is precisely the problem. Most of the user contacts 
> > that the ARG has is third-hand at best. (Combating that is one of 
> > the reasons I hang out here.) We really don't have the clear of an 
> > idea of what other Ada users want. I know I draw on my own experience 
> > far more than probably is healthy. 
> > 
> > Moreover, we've been asking for years for users to show us the 
> > problems that they cannot solve with Ada (now Ada 2012), so that we 
> > can look at possible solutions. 

> Not sure have it been proposed anywhere, but a common ABI (application 
> binary interface) for the most popular platforms (32-bit ARM Linux, 
> 64-bit x86_64/amd64 Linux, 32-bit i386 Windows, 64-bit x86_64/amd64 
> Windows) would be nice. This way I could use binary libraries generated 
> by one Ada compiler (version) with another Ada compiler (version) 
> without providing full sources (or recompilation). 

This problemspace that Tero Koskinen mentions needs either a common ABI or better (i.e., portable beyond GNAT) compile-time code generation.  C and GNAT rely on conditional compilation to select at compile-time alternative (run-time) source-code.  C++ has been relying on poor-man's functional programming via meta template programming.  Both of these are kludges for how the compile-time code-generation problemspace should be solved.  Non-gnatprep Ada has been recommending alternative selection of entire child packages as a partial solution to this problemspace.  What I envision as a robust complete solution to this problemspace is a revival of something like a.app from the 1980s/1990s Ada combined with multi-stage programming from MetaOCaml, where a Turing-complete imperative (not functional programming) Ada interpreter runs at compile time generating/selecting the next stage of(, say, run-time) source code (in 2-stage programming), which is then compiled by the Ada compiler.  And okay, if not a full-fledged compile-time Ada interpreter within the Ada compiler, then drastic expansion somehow of Ada's (currently coarse-grained) selection of (whole) child packages on a per-architecture (or per-underlying-infrastructure, e.g., GUI library, GPU library, OS API) basis.  C++'s concept-maps for the currently-postponed concepts might or might not be applicable here to map common upper-layer identifiers to a diversity of lower-layer identifiers that fan out to multiple underlying infrastructures (i.e., various software infrastructures and/or various hardware architectures).  Or a Turing-complete a.app-successor might be the better full solution than C++'s concept maps for such adaptation of single portable upper layers of Ada source code to a diversity of unruly infrastructures underneath.