From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.182.108.136 with SMTP id hk8mr16437352obb.11.1398785964863; Tue, 29 Apr 2014 08:39:24 -0700 (PDT) X-Received: by 10.182.107.136 with SMTP id hc8mr82114obb.23.1398785964754; Tue, 29 Apr 2014 08:39:24 -0700 (PDT) Path: backlog3.nntp.dca3.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!l13no11976244iga.0!news-out.google.com!en3ni366igc.0!nntp.google.com!uq10no367147igb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 29 Apr 2014 08:39:24 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=96.226.229.38; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 96.226.229.38 References: <7f1c01c5-3563-4b94-9831-152dbbf2ecdc@googlegroups.com> <206rutb9pqak$.11a3dufqvmrm4.dlg@40tude.net> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <9f55686e-89c2-4558-a405-14af376ad0b3@googlegroups.com> Subject: Re: Your wish list for Ada 202X From: "Dan'l Miller" Injection-Date: Tue, 29 Apr 2014 15:39:24 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: number.nntp.dca.giganews.com comp.lang.ada:186164 Date: 2014-04-29T08:39:24-07:00 List-Id: 2014/04/29 09:26 Tero Koskinen: > 26.3.2014 23:06, Randy Brukardt wrote:=20 > > Commenting here is precisely the problem. Most of the user contacts=20 > > that the ARG has is third-hand at best. (Combating that is one of=20 > > the reasons I hang out here.) We really don't have the clear of an=20 > > idea of what other Ada users want. I know I draw on my own experience= =20 > > far more than probably is healthy.=20 > >=20 > > Moreover, we've been asking for years for users to show us the=20 > > problems that they cannot solve with Ada (now Ada 2012), so that we=20 > > can look at possible solutions.=20 > Not sure have it been proposed anywhere, but a common ABI (application=20 > binary interface) for the most popular platforms (32-bit ARM Linux,=20 > 64-bit x86_64/amd64 Linux, 32-bit i386 Windows, 64-bit x86_64/amd64=20 > Windows) would be nice. This way I could use binary libraries generated= =20 > by one Ada compiler (version) with another Ada compiler (version)=20 > without providing full sources (or recompilation).=20 This problemspace that Tero Koskinen mentions needs either a common ABI or = better (i.e., portable beyond GNAT) compile-time code generation. C and GN= AT rely on conditional compilation to select at compile-time alternative (r= un-time) source-code. C++ has been relying on poor-man's functional progra= mming 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 comp= lete solution to this problemspace is a revival of something like a.app fro= m the 1980s/1990s Ada combined with multi-stage programming from MetaOCaml,= where a Turing-complete imperative (not functional programming) Ada interp= reter runs at compile time generating/selecting the next stage of(, say, ru= n-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 interprete= r within the Ada compiler, then drastic expansion somehow of Ada's (current= ly coarse-grained) selection of (whole) child packages on a per-architectur= e (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 div= ersity of lower-layer identifiers that fan out to multiple underlying infra= structures (i.e., various software infrastructures and/or various hardware = architectures). Or a Turing-complete a.app-successor might be the better f= ull solution than C++'s concept maps for such adaptation of single portable= upper layers of Ada source code to a diversity of unruly infrastructures u= nderneath.