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.36.7.140 with SMTP id f134mr5040974itf.36.1520269058862;
        Mon, 05 Mar 2018 08:57:38 -0800 (PST)
X-Received: by 10.157.46.5 with SMTP id q5mr811707otb.10.1520269058729; Mon,
 05 Mar 2018 08:57:38 -0800 (PST)
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!feeder.erje.net!1.eu.feeder.erje.net!weretis.net!feeder4.news.weretis.net!border2.nntp.ams1.giganews.com!nntp.giganews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.am4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!e10no1412707itf.0!news-out.google.com!a2ni3279ite.0!nntp.google.com!w142no1408626ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Mon, 5 Mar 2018 08:57:38 -0800 (PST)
In-Reply-To: <p7cbpb$s97$1@dont-email.me>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=47.185.233.194;
 posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo
NNTP-Posting-Host: 47.185.233.194
References: <5a8e17dc-1d52-4393-be58-8881e741c3a4@googlegroups.com>
 <p7cbpb$s97$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <6c844b1c-5558-47d1-8882-517d4f421166@googlegroups.com>
Subject: Re: Embeddinator-4000 begetting an Ada-cross-platform future?
From: "Dan'l Miller" <optikos@verizon.net>
Injection-Date: Mon, 05 Mar 2018 16:57:38 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 6681
X-Received-Body-CRC: 4216887869
Xref: reader02.eternal-september.org comp.lang.ada:50813
Date: 2018-03-05T08:57:38-08:00
List-Id: <comp.lang.ada>

Dan'l Miller wrote:=20
> > Although none of this supports Ada at this time, let's walk along a=20
> > path of the present (0) and emerging (1 through 3) and a potential=20
> > future (4 through 8) together.=20
Ivan Levashev wrote:
> Before reading about minor miracles, I would recommend reading=20
> Release-to-Release Binary Compatibility in SOM. It has a nice table, and=
=20
> most noted are still behind. Those who crafted this table probably did=20
> not want to make a map being valid for 20 years, but we are still there,=
=20
> like in 1408 movie.=20
>
> If you take a closer look at WinRT in C++, you'll see that it is not=20
evolved much compared to COM, ... [snip] ...

Because this is along the threads of a posting about bringing =E2=80=A2comp=
ile=E2=80=A2-time =E2=80=A2=E2=80=A2source-code projections=E2=80=A2=E2=80=
=A2 of OSes' SDKs to Ada (and to C++, as another processor-native compiled =
language, for that matter), the gist of Ivan's reply is apparently somethin=
g to the effect of:  because of lack of much progress on ABI-based extensib=
ility without additional (re)compilation of the app's original source-code =
(or the API declarations on which the app's original source code relies), i=
nterest in permitting Ada (and C++, for that matter) to compile source code=
 successfully to target iOS, Android, and Tizen is ______<insert something =
(tacitly?) negative here that Ivan doesn't quite directly mention_____.

Yes, in the most absolutely perfect world over the past 20+ years, yes, OS/=
2-era SOM-esque technologies would have been embraced on Microsoft OSes, Ap=
ple OSes, Google OSes, and Samsung OSes (and Linux and BSD Unix and all the=
 RTOSes) and it wouldn't have faded away as OS/2 and Silicon Graphics faded=
 away into history with only a few echoes of themselves still (barely) exis=
ting in a few nooks & crannies of the industry (e.g., MIPS ISA in a few net=
work processors and in PRChina's Loonson/Godson processor research; OS/2 st=
ill available for purchase at an IBM partner).

But such ABI-based extensibility without (re)compilation is effectively a l=
uxury that even the most-multi-billion-dollar corporations nowadays are unw=
illing to fund.  Apple gives some occasional statements regarding a desire =
to stabilize Swift's (and perhaps Objective-C's as prerequisite?) ABI, but =
such perennial statements in recent years are eclipsed by a rather signific=
ant =E2=80=A2increase=E2=80=A2 in churn in the APIs at the source-code-of-S=
DKs level.  Hence Apple's OSes have not yet even achieved API/source-code s=
tability, let alone ABI discipline.  Microsoft is in an even weirder situat=
ion with ever-present presumption (and release of SDK previews) for a Windo=
ws 10 Mobile OS without any new phones or non-Surface-with-less-than-full-f=
ledged-Windows-10-or-10S-OS for several years.  There are continued rumors =
of a Surface Phone or a return of a 2-LCD-screen Courier-esque phone on whi=
ch Windows 10 Mobile would run.  Google appears to be de-emphasizing their =
prior goal of having all Android apps run on all ChromeOS devices, but rath=
er Google is apparently pursuing a replacement Fuscia OS for both Android a=
nd ChromeOS that would serve both marketspaces.  Samsung's Tizen is apparen=
tly seeking an eventual de-emphasis (or divorce) from Android (perhaps at t=
he same time as Google's rollout of Fuscia OS).  So clearly Apple, Microsof=
t, Google, and Samsung have their OS/SDK hands quite (over-)full just getti=
ng pre-SOM-era source-code-centric SDK house in order, without considering =
SOM-esque luxuries at the ABI no-recompilation-needed level.  It is hard en=
ough to build out all this new OS technology for SDK source-code compilatio=
n that they are apparently too busy to language-project the source-code-API=
 for the SDK to any languages other than their golden-child walled-garden l=
anguages (i.e., Swift & Objective-C on Apple OSes, Java on Android & Chrome=
OS, C# & F# & C++/CX on Microsoft OSes).  They apparently have no time or f=
unding for SOM-esque luxuries at the ABI level.

Taking all that as the inventory of (even the bleeding edge of) the state-o=
f-the-art for 22+ years since that that article was written, these threads =
of this original posting merely beg for Ada (and ISO-standard not-divided-b=
y-CX C++ for that matter) to achieve at least 2nd-class-citizen residency o=
n the UI/UX code of Apple's, Microsoft's, and Google's OSes, instead of bei=
ng forever relegated to the dungeon of backend libraries without UI/UX resp=
onsibilities.  Via Xamarin/Mono, C# achieved 2nd-class-citizen residency on=
 the UI/UX code of Apple's, Microsoft', and Google's OSes via source-code-b=
ased language-projection of SDK API plus Xamarin-provided glue code between=
 app & OS's (fluid) ABI for each release.  (Tizen already has embraced stan=
dard C++, as I understand it, so interworking with Ada has somewhat more ho=
pe for less barrier to entry sooner.)  Language-projecting at the source-co=
de level of an SDK and then compiling is so much more practical at this inv=
entorying of the state of the art of the industry than wishing for (and wor=
se, waiting for) some sort of grand & glorious SOM-esque knight to ride in =
on his (or her) horse to save the day at the ABI level.