Embeddinator-4000 begetting an Ada-cross-platform future?

Embeddinator-4000 begetting an Ada-cross-platform future?

[Dan'l Miller]

Although none of this supports Ada at this time, let's walk along a path of the present (0) and emerging (1 through 3) and a potential future (4 through 8) together.

0) Xamarin has accomplished a minor miracle of providing Xamarin.iOS, Xamarin.Mac, Xamarin.Android, and the forthcoming Xamarin.Tizen for developing software in the iOS, MacOS, Android, and Tizen OSes, using substantially the same C# culture of presenting the Objective-C iOS runtime, the Objective-C MacOS runtime, the Java-JVM Android runtime, and the Tizen C++ development SDK to C# on top of the Mono stack.

https://github.com/Microsoft/cppwinrt
https://moderncpp.com/2017/11/15/cppwinrt-exe-in-the-windows-sdk

1) Microsoft (actually the genius Kenny Kerr prior to being hired at Microsoft) has accomplished a minor miracle of generating ISO 14882:2017 C++ source code to invoke any WinRT component that has a .DLL and its accompanying .winMD (Windows metadata, which provides symbolic names among other rich information).  WinRT components are not limited to only WinRT (a.k.a. UWP).  Nowadays nearly all of Windows SDK and nearly all of .NET world (other than Mono) is presented as WinRT components, which are effectively a modernized version of ATL & COM from the older era of Microsoft.  This code generator is called cppwinrt.exe and the body of work that it generates is called C++/WinRT.  The generated code has some annoying C++ish peculiarities, such as all would-be(-in-C++/CX-or-C#) “types” are actually value-semantics object instances.  Of course, such peculiarities would be anathema to Ada culture, but still:  consider a world where (all) processor-native languages need not be extended with C++/CLI-esque or C++/CX-esque grafted-on C#-esque languages in order to invoke (or be invoked by) UWP and .NET runtimes.

https://github.com/mono/embeddinator-4000

2) Mono's Embeddinator-4000 has been also accomplishing another minor miracle of generating Java and Objective-C façades to any Mono DLL, especially the Xamarin.iOS, Xamarin.MacOS, Xamarin.Android, and so forth language projections of the iOS, MacOS, Android, and so forth SDKs.

3) Mono's Embedinnator-4000 could have a C++ language projection relatively soon for Clang to invoke the Objective-C runtime of iOS, the Objective-C runtime of MacOS, and (analogous to the way Xamarin.Android works) the JVM-based Java runtime of Android (externally, forcibly) via the JNI, and even perhaps a competitor to C++/WinRT for UWP.  Imagine Xamarin.iOS's, Xamarin.Mac's, Xamarin.Android's SDKs' APIs language-projected to ISO-14489-compliant C++.  Embeddinator-4000 generating a non-C++/WinRT C++ language projection of nonMono .NET SDKs for UWP or Windows 10 are conceivable.  Embeddinator-4000 generating a C++ language projection of Xamarin.Tizen SDK's APIs is also conceivable, as Xamarin.Tizen becomes a 1st-class citizen in the Xamarin/Mono world.  Btw, in case some reader is failing to grasp the import of this:  the miracle of Embeddinator-4000 (and of C++/WinRT for that matter) is not to generate the language projection of the API itself (although it does that).  Rather the key is that Embeddinator-4000 generates the glue code from that language projection of the SDK to the runtime of the SDK.  Some thin roll-your-own veneer code-generator is not what this is.  This is the real full invokable language projection of the SDK into other languages, really reading the Objective-C-runtime binaries and the JVM binaries to invoke those binaries from other languages.

4) Imagine an LLVM-backend for GNAT, so that GNAT can be debugged symbolically on iOS devices, instead of the current lack thereof.  (I am not talking about some old musty crusty Dragon Egg either, based on GCC 4.2.)  Is there any news on the current state of this?

5) Imagine a future release of Mono's Embeddinator-4000 that also would generate an Ada language projection of Xamarin's C# SDKs' APIs for all those OSes, somewhat mimicking the more-Ada-esque portions of Embeddinator-4000's language projections to the current Java, the current Objective-C, and/or the forthcoming C++.

6) Suddenly, shortly after the forthcoming advent of C++ as a processor-native language that can be utilized to write iOS apps instead of in Objective-C or in Swift or in Xamarin.iOS's C#, to write MacOS apps instead of in Objective-C or in Swift or in Xamarin.Mac's C#, to write Android apps instead of in Objective-C or in Swift or in Xamarin.Android's C#, and to write UWP apps on Microsoft Windows 10 editions of OSes instead of in .NET's C# or F# or C++/CX or C++/WinRT, then right on the heels of that (!) Ada could then be the 2nd processor-native language capable of writing apps for iOS, MacOS, Android, UWP, and eventually Tizen.  If C++ language projection in Embeddinator-4000 continues to fail to be released (as it has throughout 2017), then Ada could actually pull ahead in the race to be the 1st processor-native cross-platform language for all those OSes.

7) Suddenly, developers start considering C++ or Ada as a viable alternative to writing their apps as many as 6 times:
7.1) once in Swift or Objective-C for iOS;
7.2) again porting their mobile Swift or Objective-C app to desktop MacOS de-emphasizing the mobile UI/UX emphasizing window frames & menus, again;
7.3) again in Java or Kotlin for Android;
7.4) again in C# or F# or C++/CX or C++/WinRT for UWP (store app);
7.5) again porting their mobile UWP app to desktop or non-store Windows 10;
7.6) again in C++ for Tizen.

Oh, and Google is developing some sort of successor to Android and ChromeOS called Fuscia, so perhaps that might be the 7th rewriting/major-porting effort.

https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52

8) With Viper software architecture replacing MVC and MVVM software architecture in GUI and mobile apps, the nonportable OS-specific UI code in each View can be divorced from the cross-platform UX code in each Presenter (and Router for navigation segueing).
8.1) If this quarantining of nonportable UI code in the Viper Views is not enough, an Ada analogue of (the deeply flawed) Xamarin.Forms could be designed for true portability of commonplace abstractions of UI in each portable View, leaving only a few nonportable Viper Views that each take advantage of highly peculiar-to-1-OS UI features.

As perhaps the only 3 languages in the future to accomplish this degree of writing the UI/UX for all these OSes in the same language with the same (e.g., Reactive Extensions) programming-culture libraries, then C#, C++, and Ada can compete on their respective merits for dominance in the cross-platform domain, leaving Java, Kotlin, Swift, and Objective-C relegated to their relatively-walled-garden single-company narrower marketspaces, analogous to BLISS on DEC minicomputers, to PL/I on IBM and Multics versus PL/P on PrimOS versus PL/M on CP/M, and Protel on Nortel telephone equipment.  I bring up those historical examples, because the future is ripe for history repeating itself in the next half-decade or so.

This is tomorrow's carpe diem.  Seize it (or be a victim of natural selection's survival of the fittest).

Embeddinator-4000 begetting an Ada-cross-platform future?

[Dan'l Miller]

“… to write Android apps instead of in Objective-C or in Swift or in Xamarin.Android's C# …” should have been ‘… to write Android apps instead of in Java or in Kotlin or in Xamarin.Android's C# …’  I apologize for this copy-paste mistake.  (But this is analogous to the brain drifts that occur when writing substantially ‘the same’ apps as many as 6 or 7 times in slightly different languages with different programming-culture libraries for different SDKs:  too many slight differences fatigues the short-term memory.  Eliminating the different languages and the different programming-culture libraries, leaving only different SDKs would restore a proper degree of being able to focus on only the OS-specific differences that matter without distraction from different languages and different nonSDK libraries.)

Re: Embeddinator-4000 begetting an Ada-cross-platform future?

[Mehdi Saada]

Exactly, one <barred> Ring </barred> Language to rule them all !
... Sorry, couldn't resist.
Yet, it's my earnest wish. How far more advanced would we be if it was reality ?

Re: Embeddinator-4000 begetting an Ada-cross-platform future?

[Dan'l Miller]

“My Preciousssssssss!” is within reach closer than it has ever been before.  This thread isn't completely science-fiction fantasy; a few fronts are moving forward concurrently.  Either Ada or C++ will get there first, depending on how much momentum builds behind each one and how much one looks over the other's open-source shoulder.

Re: Embeddinator-4000 begetting an Ada-cross-platform future?

[Luke A. Guest]

There is an iOS target for gnat but we don’t have access to it as it’s
internal.

What are you doing to help?

Re: Embeddinator-4000 begetting an Ada-cross-platform future?

[Luke A. Guest]

Luke A. Guest <laguest@archeia.com> wrote:
> There is an iOS target for gnat but we don’t have access to it as it’s
> internal.
> 

There is jgnat and A# but unfortunately the rts is all GPL v3. Which
doesn’t help.

Re: Embeddinator-4000 begetting an Ada-cross-platform future?

[Dan'l Miller]

JGNAT and A# are both no longer supported, and haven't been for a number of years.  They both have certainly undergone bit-rot since then, to the point of needing serious overhaul to once again work with the wavefront of GNAT development.  So bringing them up is a non sequitur, for not only the reason of being defunct, but also they (unwisely) run on the JVM & CLR virtual machines instead of invoke the SDKs via processor-native machine-code (as, say, C++/WinRT does for .NET via WRL-to-ATL-to-COM and Xamarin.Android does for Java via the JNI).  So neither JGNAT nor A# are pursuant to this thread's sought-after goal of invoking SDKs in VMs via processor-native machine-code compiled from Ada or C++.

Re: Embeddinator-4000 begetting an Ada-cross-platform future?

[Ivan Levashev]

27.02.2018 3:35, Luke A. Guest пишет:
> Luke A. Guest <laguest@archeia.com> wrote:
>> There is an iOS target for gnat but we don’t have access to it as it’s
>> internal.
>>
>
> There is jgnat and A# but unfortunately the rts is all GPL v3. Which
> doesn’t help.
>
And there is AdaMagic in MapuSoft, probably not that costly.

And there is SPARK2C emerging inside AdaCore.

Best Regards,
Ivan Levashev,
Barnaul

--
If you want to get to the top, you have to start at the bottom

Re: Embeddinator-4000 begetting an Ada-cross-platform future?

[Dan'l Miller]

Speaking conservatively and not over-committing, I am inventorying the gaps in the various segments of the C++ community to see where they are going with regards to Embeddinator-4000's C++ code generation on all these OSes/SDKs.  The biggest question is what Microsoft(-owned? Mono's) Embeddinator-4000 is going to generate as the C++ language projection on Windows.  Will Embeddinator-4000 defer to C++/WinRT?  Or will Embeddinator-4000 devise a Mono-centric competitor to C++/WinRT's .winMD approach?  (Mono is effectively a clone of .NET for all the non-Microsoft OSes, and, due to its history, Mono lacks .winMD rich metadata embellishing a .DLL.)  If they defer to C++/WinRT on Windows, does that jeopardize the entire motivation for a C++ language projection in Embeddinator as diluting either the C++/WinRT or Xamarin momentum at Microsoft.  The question is:  how much autonomy does Mono have in this new Xamarin-owned Microsoft era?  And how much ‘internal’ competition does Xamarin or Microsoft want to incur from C++ vis a vis Xamarin.iOS, Xamarin.Mac, Xamarin.Android, Xamarin.Tizen, and eventually Xamarin.Forms. The autonomy question is interesting only in the sense of how much C++ support will the Mono team build out in Embeddinator-4000 versus how much will they be steered by interdepartmental pressures to do or not do certain things regarding the C++/WinRT momentum that is building in Microsoft and the Xamarin C# momentum that is already in full force.  Of course, these are not questions for this group, but you asked what I was contributing to the topic, and the Ada topic depends on all these other tangents, either directly as dependency/pioneer or indirectly as ‘office politics’ as this all plays out.

Plus, I am acting as breaking-news journalist here in this group, reporting news of sorts from afar of which the Ada community might not be aware.  You'd rather hear fresh news as it is happening in early 2018, rather than hearing for the first time how it all turned out after the fact in, say, 2020.

I think you are indirectly asking, ‘Are you going to pursue any open-source extension of Embeddinator-4000 to add the Ada language projection?’.  Without over-committing and without rejecting the idea, I will give you this big hint:  because of the lack of Ada symbolic debugging on iOS devices, I am forced to do my cross-platform iOS, MacOS, Android, UWP, Tizen development of ‘the same’ app in C++ (including its variants C++/CX or C++/WinRT and Objective-C++) until such an Ada compiler exists.  In my C++ cross-platform development for those platforms using the VIPER architecture to quarantine per-OS/per-SDK oddities into VIPER Views, I currently completely lack a nonJava/nonKotlin solution for writing the UI in any variant of C++.  Due to this lack, the JNI boundary between the VIPER Presenters and the VIPER Views rears its ugly head in hand-crafted app-domain source code (in the VIPER Views), rather than being buried in infrastructure as auto-generated forget-about-it it-just-works nicety.  So the one missing language projection from Embeddinator-4000 that I most need is the C++ language projection for Xamarin.Android's JNI-based invocation of Android's Java SDK.  But to get the Android language projection, if I were to develop the C++ language projection myself (and cease waiting for the ever-forthcoming one to finally arrive), it would be approximately the same amount of work as developing the Ada one.  The main thing that stops me from developing the Ada one is the lack of symbolic debugging on iOS, due in turn to the lack of LLVM-backend toolchain that Apple demands, since GCC is no longer permitted by Apple.  To keep score in my world, I have 2 gaps for Ada (lack of LLVM and lack of Embeddinator-4000) versus 1 gap for C++ (lack of Embeddinator-4000).  The effort for hand-crafting the VIPER View quarantining of Android/JVM/Java SDK is approximately the same as developing a Embeddinator-4000 language projection, so hand-crafting it in the app-domain effectively score a gap of 1 as well.  If this thread would happen to reveal how soon the LLVM backend for GNAT is coming, then that could adjust Ada's gap-analysis scoring to be effectively 1 instead of 2, causing all options to be effectively tied in foreseeable effort.

Re: Embeddinator-4000 begetting an Ada-cross-platform future?

[Luke A. Guest]

Dan'l Miller <optikos@verizon.net> wrote:

A simple question deserves a simple answer, not reams of cut n pasted text,
which I won’t read.


> I think you are indirectly asking, ‘Are you going to pursue any
> open-source extension of Embeddinator-4000 to add the Ada language
> projection?’.  Without over-committing and without rejecting the idea, I
> will give you this big hint:  because of the lack of Ada symbolic debugging on iOS devices,

You’re missing the point that there is no Ada toolchain available,
publicly, for iOS, not just a debugger.

Re: Embeddinator-4000 begetting an Ada-cross-platform future?

[Dan'l Miller]

I did not say LLVM debugger in isolation.  I said LLVM (the whole enchilada).  The only way to get an Ada LLVM symbolic-debugging-session capability for apps deployed to actual iOS devices (not on simulators on MacOS) is to have a GNAT with LLVM backend capable of generating Apple's ARM-target executables & shared libraries plus symbol files that are all consumable by XCode's toolchain via supplemental files that define the Ada constructs/syntax & ABI to the Apple-certficate-signed LLVM debugger.  One does not get the last step (symbolic debugging on iOS) without a whole chain of prerequisites that accumulate to make it possible—hence the term toolchain.

Re: Embeddinator-4000 begetting an Ada-cross-platform future?

[Randy Brukardt]

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:a870e693-31ef-4507-b16f-2ce1d01badb6@googlegroups.com...
>I did not say LLVM debugger in isolation.  I said LLVM (the whole
>enchilada).  The only way to get an Ada LLVM symbolic-debugging-
>session capability for apps deployed to actual iOS devices (not on
>simulators on MacOS) is to have a GNAT with LLVM backend ...

Why has Ada turned into GNAT here? Ada /= GNAT, and it's quite possible that 
some other Ada compiler is a better match for LLVM.

                                       Randy.

Re: Embeddinator-4000 begetting an Ada-cross-platform future?

[Dan'l Miller]

I am all ears.  Please tell me more about any forthcoming LLVM backend on other Ada compilers.

Re: Embeddinator-4000 begetting an Ada-cross-platform future?

[Dan'l Miller]

Other than language-projecting via full automation the SDKs of modern popular OSes to Ada (as proposed here via extending Embedinnator-4000 for language-projections to Ada in much the same way that it is being extended for language-projections to C++), what else can be done to invigorate excitement about Ada as a better competitor to C++ in all of C++'s marketspaces?  C++/WinRT is apparently rehabilitating C++ within Microsoft in areas of the company where UI/UX performance or UI/UX interfacing with C++/processor-native-compiled-language backend processing is coming under increasing scrutiny.  Other than lacking symbolic debugging on iOS devices (and a few LLVM-backend-oriented prerequisites thereof), there is no real reason for Ada to be left out of C++'s recent advances in enacting a C++ comeback.

https://docs.ElementsCompiler.com

Vaguely analogously, RemObjects is making a similar-but-technically-quite-different ploy as its breakthrough marketing strategy:  ObjectPascal (rebranded as Oxygene) and C# (rebranded as Hydrogene) and Java (rebranded as Iodine) and Swift (rebranded as Silver) are being merged into one enormous confederated compiler (branded as Elements) with a shared(-to-some-degree) AST, so that apps can be written in any of {Java, Swift, C#, ObjectPascal} on all of the {Windows, desktop Java SDK, Android SDK, Objective-C SDK for iOS, Objective-C SDK for MacOS}.  No one else has Java or Swift targeting the Windows SDK.*  No one else has Java targeting the iOS or MacOS SDKs.*  Not even C#-everywhere Xamarin has C# app development •both• 1) inside the JVM able to invoke (and be invoked by) Java or Kotlin easily & intimately and 2) in processor-native machine code outside the JVM for backend-processing libraries and for invoking (and being invoked by) app-domain JNI bridges (as opposed to Xamarin.Android's C#-to-SDK infrastructural bridges, not at the app-domain level).  Wouldn't it be awesome for one of the Ada-compiler vendors to have a joint-venture or ownership relationship with RemObjects to bring Ada into the Elements confederated-compiler world that would suddenly open Ada up to targeting Android, iOS, and MacOS (and the JVM & CLR again)?

* other than defunct unmaintained one-off experiments years ago

A much bigger marketspace is within Ada's reach.  Other languages and other compiler vendors are pioneers into new frontiers.  There is no real reason for Ada & its compiler vendors to not be among those pioneers at the same time right now.

Re: Embeddinator-4000 begetting an Ada-cross-platform future?

[Lucretia]

On Wednesday, 28 February 2018 15:55:13 UTC, Dan'l Miller  wrote:

> https://docs.ElementsCompiler.com

Another closed, i.e. proprietary, compiler isn't going to help Ada, another free one will.

Re: Embeddinator-4000 begetting an Ada-cross-platform future?

[Dan'l Miller]

Lucretia wrote:
> Another closed, i.e. proprietary, compiler isn't going to help Ada, another free one will. 

Anyone can have another open-source Ada compiler whenever so desire:
1) Fork the FSF copy, so as to (apparently?) have the proper license.
2) Put an LLVM backend on it.  Either modernize Dragon Egg itself or conceptually repeat the entirety of Dragon Egg's old work differently in a more-modern release of GNAT and GCC.
3) Indeed, even ASIS it to semi-automatedly drastically refactor/overhaul the Ada code in which GNAT is written.  Even do this gratuitously for no reason to inhibit merging it back into FSF easily (unless someone else develops the anti-refactorer to recursively unwind the deeply-accumulated divergent ASIS-assisted refactorings).
4) Always contribute all such evolution in GPL-compliant ways, such as on GitHub.
5) Go merrily on your way, never looking back at FSF (or at AdaCore).

The big problem is never begetting the open-source repository itself for a 2nd open-source Ada compiler.  The big problem is how to fund an open-source business model.  (Hence, why closed-source business models arise for entirely-different not-GPLed source-code bases.)

Conversely, I would pay relatively-small-but-still-substantial amounts of money (less than $1000 per year per seat) for a proprietary closed-source Ada toolchain so that I could write both nonportable/SDK-specific UI/UX and portable backend-processing libraries all in Ada on iOS, MacOS, and Android.  Being closed-source is a non sequitur if the affordable compiler vendor is fairly rapidly responsive to new Ada language definitions and to bug fixes and to having a VisualStudio/XCode level of IDE user experience (e.g., what JetBrains provides in ReSharper extensions to VisualStudio and in stand-alone IDEs for the JetBrains-supported languages {C++, C#, Java, Kotlin}).

Re: Embeddinator-4000 begetting an Ada-cross-platform future?

[Dan'l Miller]

Lucretia wrote: 
> Another closed, i.e. proprietary, compiler isn't going to help Ada, another free one will.

... or do you mean an open-source Ada compiler that has a more-permissive/less-viral license than GMGPL, such as MIT or BSD?  The technique itemized in my prior comment above cannot derive from GNAT into another nonGMGPL license, of course.

Re: Embeddinator-4000 begetting an Ada-cross-platform future?

[Shark8]

On Wednesday, February 28, 2018 at 12:20:49 PM UTC-7, Dan'l Miller wrote:
> Lucretia wrote:
> > Another closed, i.e. proprietary, compiler isn't going to help Ada, another free one will. 
> 
> Anyone can have another open-source Ada compiler whenever so desire:
> 1) Fork the FSF copy, so as to (apparently?) have the proper license.
Why? This will inherit *ALL* of GNAT's flaws and limitations.

> 2) Put an LLVM backend on it.  Either modernize Dragon Egg itself or conceptually repeat the entirety of Dragon Egg's old work differently in a more-modern release of GNAT and GCC.
You could do that with a non-GCC compiler.

> 3) Indeed, even ASIS it to semi-automatedly drastically refactor/overhaul the Ada code in which GNAT is written.  Even do this gratuitously for no reason to inhibit merging it back into FSF easily (unless someone else develops the anti-refactorer to recursively unwind the deeply-accumulated divergent ASIS-assisted refactorings).
This seems a bit convoluted; I'm not sure I get your meaning, or purpose here.

> 4) Always contribute all such evolution in GPL-compliant ways, such as on GitHub.
*SIGH* -- There's the start of a MIT-licensed compiler, Byron, I have on GitHub. -- https://github.com/OneWingedShark/Byron -- but there's only one contributor.

> 5) Go merrily on your way, never looking back at FSF (or at AdaCore).
Why even look to them to begin with?

> The big problem is never begetting the open-source repository itself for a 2nd open-source Ada compiler.
Objectively false; see above.
The big problem is that there's only one contributor, and he's disgusted with his lack of progress.

> The big problem is how to fund an open-source business model.  (Hence, why closed-source business models arise for entirely-different not-GPLed source-code bases.)
Not really -- there's plenty that can be done with (a) support contracts, and/or (b) specialized/additional tooling.

> Conversely, I would pay relatively-small-but-still-substantial amounts of money (less than $1000 per year per seat) for a proprietary closed-source Ada toolchain so that I could write both nonportable/SDK-specific UI/UX and portable backend-processing libraries all in Ada on iOS, MacOS, and Android.  
Turbo Pascal proved that a company could thrive by targeting small-businesses and hobbyists with relatively cheap compilers.

Re: Embeddinator-4000 begetting an Ada-cross-platform future?

[Dan'l Miller]

Dan'l Miller wrote:
> > Anyone can have another open-source Ada compiler whenever so desire: 
> > 1) Fork the FSF copy, so as to (apparently?) have the proper license. 
Shark8 wrote:
> Why? This will inherit *ALL* of GNAT's flaws and limitations.

Hence the aforementioned ASIS automation-assisted accumulation of refactorings.  Grind the concrete up into powder again; shape that soft clay quite differently.

Dan'l Miller wrote:
> > 2) Put an LLVM backend on it.  Either modernize Dragon Egg itself or conceptually repeat the entirety of Dragon Egg's old work differently in a more-modern release of GNAT and GCC. 
Shark8 wrote:
> You could do that with a non-GCC compiler. 

Of course.  For example, one of today's proprietary Ada compilers could do that.  (And if, for some reason, they wanted to change their business model, they could optionally open-source their new LLVM-backended Ada compiler.)

Dan'l Miller wrote:
> > 3) Indeed, even ASIS it to semi-automatedly drastically refactor/overhaul the Ada code in which GNAT is written.  Even do this gratuitously for no reason to inhibit merging it back into FSF easily (unless someone else develops the anti-refactorer to recursively unwind the deeply-accumulated divergent ASIS-assisted refactorings). 
Shark8 wrote:
> This seems a bit convoluted; I'm not sure I get your meaning, or purpose here.

Instead of starting from a blank text editor like you apparently did, one could start with GNAT and then drastically drastically overhaul it top to bottom.  The biggest downside would be the derivative-work result couldn't be any license other than GMGPL (or worse GPL).

Dan'l Miller wrote:
> > 4) Always contribute all such evolution in GPL-compliant ways, such as on GitHub. 
Shark8 wrote:
> *SIGH* -- There's the start of a MIT-licensed compiler, Byron, I have on GitHub. -- https://github.com/OneWingedShark/Byron -- but there's only one contributor. 

My step 4 was predicated on the prior steps.  Of course, if you start with a blank text editor instead of GNAT, then yes, you can contribute the open-source Ada compiler under some other license than GMGPL (or GPL).  Btw, awesome initiative & effort!  There was a time 3 decades ago where Andrew Tannenbaum was at the same point with Minix, which Linus Torvalds then extended into Linux.  Big things can start with a single passionate individual acting alone (assuming the Andrew Tannenbaum didn't have all his grad students helping him out immensely).

> > 5) Go merrily on your way, never looking back at FSF (or at AdaCore). 
> Why even look to them to begin with? 

When starting with a blank text editor as you apparently have, then correct, you want to clean-room your design so that you don't (even subconsciously) mimic anything in GNAT, so that you don't create a (GMGPLed or GPLed) derivative work.  But for the technique that I enumerated in this thread, one would intimately critique each and every design decision in GNAT to perhaps drastically alter it via the aforementioned ASIS-assisted refactorings.

Dan'l Miller wrote:
> > The big problem is never begetting the open-source repository itself for a 2nd open-source Ada compiler. 
Shark8 wrote:
> Objectively false; see above. 
> The big problem is that there's only one contributor, and he's disgusted with his lack of progress. 

False in the world in which your logic is operating, but true outside of your start-from-a-blank-text-editor world.  (I am using modal logic's definition of possible-world logic there.  https://en.wikipedia.org/wiki/Possible_world )  Using the technique that I enumerated, a quite-different-than(-except-for-license)-GNAT Ada open-source compiler can be squirted out as the numerous accumulations of the ASIS-assisted refactoring in probably less than one person-year effort.  Perhaps 2 person-year effort to radically set a GNAT-derivative-work on an entirely different foundation of aggressive redesign.

Dan'l Miller wrote:
> > The big problem is how to fund an open-source business model.  (Hence, why closed-source business models arise for entirely-different not-GPLed source-code bases.) 
Shark8 wrote:
> Not really -- there's plenty that can be done with (a) support contracts, and/or (b) specialized/additional tooling. 

If scraping up sufficient funding is so easy, then scrape up $500,000 to hire 5 more developers for your OneWingedShark Ada compiler so that you aren't the lone contributor.  Or likewise, if wooing corporate subsidization is so easy, then go beg at one or more Fortune 1000 corporations who frequently contribute staff time to open-source repositories that are not their own (e.g., IBM).  Yes, once you own the means of production so to speak, then, yes, you can milk & milk & milk that cash cow.  The problem is scraping up enough hundreds of thousands or millions of dollars to write the cash cow in the first place, when starting from a blank text-editor.  Hence, my point of don't limit ourselves as a community to only fresh starts with a blank text editor, such as your own laudable effort.  You are one genome.  My aforementioned list of steps are another genome.  Survival of the species is best via diverse genomes, so that at least one survives the rigors of natural selection.  To everyone other than you & your fellow contributors, please think of what a drastically-rejiggered GNAT would look like (other than the one immutable chiseled-in-stone part:  GMGPL or GPL).

Dan'l Miller wrote:
> Conversely, I would pay relatively-small-but-still-substantial amounts of money (less than $1000 per year per seat) for a proprietary closed-source Ada toolchain so that I could write both nonportable/SDK-specific UI/UX and portable backend-processing libraries all in Ada on iOS, MacOS, and Android.   
Shark8 wrote:
> Turbo Pascal proved that a company could thrive by targeting small-businesses and hobbyists with relatively cheap compilers. 

Well, yes, but back in 1983 the bar was set very low though.  Philipe Kahn's TurboPascal only needed to be better than Microsoft's BASICA or GWBASIC •interpreters• (and better than Waterloo BASIC •interpreters• largely only on fellow-Canadian Commodore) and better than UCSD p-System Pascal's p-code •virtual machine•.  All existing (incongruent-)competitors were sitting-duck targets.  Had Waterloo/WATCOM released a far-more-expensive set of impressively-optimizing compilers corresponding to their interpreters a few years sooner (or had Microsoft bought the rights to Lattice Semiconductor's C compiler a few years sooner), Philipe Kahn's TurboPascal marketspace would have been shriveled to the size of a raisin.  People didn't buy TurboPascal because it was Pascal; they (and I) bought it because it was a •compiler-to-machine-code• of any language above assembly language and we couldn't afford Digital Research's/Intel's PL/M compiler.  We didn't buy TurboPascal because it was Pascal; we bought it because it was Turbo (and cheap).

Re: Embeddinator-4000 begetting an Ada-cross-platform future?

[Shark8]

On Thursday, March 1, 2018 at 12:09:07 PM UTC-7, Dan'l Miller wrote:
> Dan'l Miller wrote:
> > Conversely, I would pay relatively-small-but-still-substantial amounts of money (less than $1000 per year per seat) for a proprietary closed-source Ada toolchain so that I could write both nonportable/SDK-specific UI/UX and portable backend-processing libraries all in Ada on iOS, MacOS, and Android.   
> Shark8 wrote:
> > Turbo Pascal proved that a company could thrive by targeting small-businesses and hobbyists with relatively cheap compilers. 
> 
> Well, yes, but back in 1983 the bar was set very low though.  Philipe Kahn's TurboPascal only needed to be better than Microsoft's BASICA or GWBASIC •interpreters• (and better than Waterloo BASIC •interpreters• largely only on fellow-Canadian Commodore) and better than UCSD p-System Pascal's p-code •virtual machine•.  All existing (incongruent-)competitors were sitting-duck targets.  Had Waterloo/WATCOM released a far-more-expensive set of impressively-optimizing compilers corresponding to their interpreters a few years sooner (or had Microsoft bought the rights to Lattice Semiconductor's C compiler a few years sooner), Philipe Kahn's TurboPascal marketspace would have been shriveled to the size of a raisin.  People didn't buy TurboPascal because it was Pascal; they (and I) bought it because it was a •compiler-to-machine-code• of any language above assembly language and we couldn't afford Digital Research's/Intel's PL/M compiler.  We didn't buy TurboPascal because it was Pascal; we bought it because it was Turbo (and cheap).

But I never said the reason that Turbo Pascal was popular because it was a Pascal; I said that it was successful targeting small-business and hobbyists, which you actually confirm. 

> Dan'l Miller wrote:
> > > The big problem is how to fund an open-source business model.  (Hence, why closed-source business models arise for entirely-different not-GPLed source-code bases.) 
> Shark8 wrote:
> > Not really -- there's plenty that can be done with (a) support contracts, and/or (b) specialized/additional tooling. 
> 
> If scraping up sufficient funding is so easy, then scrape up $500,000 to hire 5 more developers for your OneWingedShark Ada compiler so that you aren't the lone contributor.  Or likewise, if wooing corporate subsidization is so easy, then go beg at one or more Fortune 1000 corporations who frequently contribute staff time to open-source repositories that are not their own (e.g., IBM).  Yes, once you own the means of production so to speak, then, yes, you can milk & milk & milk that cash cow.  The problem is scraping up enough hundreds of thousands or millions of dollars to write the cash cow in the first place, when starting from a blank text-editor.  Hence, my point of don't limit ourselves as a community to only fresh starts with a blank text editor, such as your own laudable effort.  You are one genome.  My aforementioned list of steps are another genome.  Survival of the species is best via diverse genomes, so that at least one survives the rigors of natural selection.  To everyone other than you & your fellow contributors, please think of what a drastically-rejiggered GNAT would look like (other than the one immutable chiseled-in-stone part:  GMGPL or GPL).
 
?? -- I said that there was room enough for support-contracts and/or specialized tools to make a profit. Your supposition [of easily scraping together $500,000] relies on ignoring the implicit prerequisite of having the product (eg compiler).

This isn't to say I'm dismissing the costs of development, but AdaCore operates under the "support contract" model [and already has the compiler] and some of its actions are... puzzling and honestly bad for both Ada and itself. (See, for example, how they quit doing the JVM and DOTNET backends; or how they brand Ada as [almost] an exclusively high-integrity or embedded language.)

I get what you;re saying about "diversity of species", but the flat fact of the matter is that insofar as Ada is concerned GNAT (be it FSF or AdaCore) is the *ONLY* free [and fully-functional] option, the *ONLY* Ada 2012 option, and certainly the most common implementation among hobbyists and small-business. -- For this reason it seems like your argument should be made against GNAT.

> please think of what a drastically-rejiggered GNAT would look like

It would likely suffer from the same architectural and design limitations like GNAT does. Things like the lack of a proper library, using instead the file-system, and being unable to process multiple compilation-units per file, and so on.

Also, there's been some weird regressions/bugs in GNAT that make me think certain things aren't properly handled; example: renaming attributes throws up a bug-box. (The advised solution is to use "NAME : Constant TYPE := Obj'ATTR;")

A further disadvantage to "intensive refactor" is the fact that such efforts are normally directed to "do the same thing" rather than actually evaluate if that thing is the best way of accomplishing the goal -- as a practical example consider Continuous Integration where the typical setup is "(1) pull the current repository, (2) build the entire thing, (3) on errors/bad-build issue an alert [usu. email]" -- the whole thing can be done with far less processing if you were to combine it into the repository function as described here ( http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.26.2533&rep=rep1&type=pdf ) using a DB-tree as the repo, so that only consistent/compilable partitions are merged upwards in the DB-tree, resulting in the root-node always being consistent... combine this with existing DB-journaling and now you have a record of *ALL* successful builds.

> Dan'l Miller wrote:
> > > The big problem is never begetting the open-source repository itself for a 2nd open-source Ada compiler. 
> Shark8 wrote:
> > Objectively false; see above. 
> > The big problem is that there's only one contributor, and he's disgusted with his lack of progress. 
> 
> False in the world in which your logic is operating, but true outside of your start-from-a-blank-text-editor world.  (I am using modal logic's definition of possible-world logic there.  https://en.wikipedia.org/wiki/Possible_world ) 

I don't agree; but for the sake of argument I'll allow it.

> Using the technique that I enumerated, a quite-different-than(-except-for-license)-GNAT Ada open-source compiler can be squirted out as the numerous accumulations of the ASIS-assisted refactoring in probably less than one person-year effort.  Perhaps 2 person-year effort to radically set a GNAT-derivative-work on an entirely different foundation of aggressive redesign.

I don't know about this; while it might be theoretically possible, I haven't seen or heard of any ASIS refactoring too being used on this scale to this effect.

I know it's a point of disagreement between myself and several of my friends here on Comp.Lang.Ada, but I'm of the opinion that what we need is a standardized IR in the vein of AIR and/or DIANA -- actually a two-stage set of them -- one wherein the structures align to syntactically & semantically valid Ada, and a 'deeper'/more-general one where things are generalized and abstracted to allow a uniform composition (ie "Subtype Nybble is Integer range 0..15;", "Subtype Nybble is Integer with Static_Predicate => Nybble in 0..15, Predicate_Failure => Raise Constraint_Error;", and "Subtype Nybble is Integer with Static_Predicate => Nybble >= 0 and Nybble <= 15, Predicate_Failure => raise Constraint_Error;" should all be represented as the same thing [perhaps with some flag indicating which style is in source].)

> Dan'l Miller wrote:
> > > 4) Always contribute all such evolution in GPL-compliant ways, such as on GitHub. 
> Shark8 wrote:
> > *SIGH* -- There's the start of a MIT-licensed compiler, Byron, I have on GitHub. -- https://github.com/OneWingedShark/Byron -- but there's only one contributor. 
> 
> My step 4 was predicated on the prior steps.  Of course, if you start with a blank text editor instead of GNAT, then yes, you can contribute the open-source Ada compiler under some other license than GMGPL (or GPL).  Btw, awesome initiative & effort!

Thank you.
Though I'll admit to being stuck/frustrated on part of the parser -- it's *almost* working, and yet so far away...


> Dan'l Miller wrote:
> > > 3) Indeed, even ASIS it to semi-automatedly drastically refactor/overhaul the Ada code in which GNAT is written.  Even do this gratuitously for no reason to inhibit merging it back into FSF easily (unless someone else develops the anti-refactorer to recursively unwind the deeply-accumulated divergent ASIS-assisted refactorings). 
> Shark8 wrote:
> > This seems a bit convoluted; I'm not sure I get your meaning, or purpose here.
> 
> Instead of starting from a blank text editor like you apparently did, one could start with GNAT and then drastically drastically overhaul it top to bottom.  The biggest downside would be the derivative-work result couldn't be any license other than GMGPL (or worse GPL).

The GPL license is one of the reasons that small-businesses are steered away from Ada -- in short, the viral nature makes them quite leery of using Ada at all because, from their perspective, the license is all legal liability and doesn't protect them. (There've been several instances of this coming up right here on comp.lang.ada, in fact.)

It's one reason I think "major refactor" won't work out the way you're thinking it will -- granted, I certainly could be wrong in my estimation.

> Dan'l Miller wrote:
> > > 2) Put an LLVM backend on it.  Either modernize Dragon Egg itself or conceptually repeat the entirety of Dragon Egg's old work differently in a more-modern release of GNAT and GCC. 
> Shark8 wrote:
> > You could do that with a non-GCC compiler. 
> 
> Of course.  For example, one of today's proprietary Ada compilers could do that.  (And if, for some reason, they wanted to change their business model, they could optionally open-source their new LLVM-backended Ada compiler.)
 
Perhaps, I know there's at least four or five people here who would love to see an LLVM backend.


> Dan'l Miller wrote:
> > > Anyone can have another open-source Ada compiler whenever so desire: 
> > > 1) Fork the FSF copy, so as to (apparently?) have the proper license. 
> Shark8 wrote:
> > Why? This will inherit *ALL* of GNAT's flaws and limitations.
> 
> Hence the aforementioned ASIS automation-assisted accumulation of refactorings.  Grind the concrete up into powder again; shape that soft clay quite differently.

Allow me to reiterate: I think this wouldn't solve the inherent limitations, nor be conducive to reevaluating "the way we've always done it" for a better approach/process.

Re: Embeddinator-4000 begetting an Ada-cross-platform future?

[Randy Brukardt]

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:e067f080-1eb6-4c23-82cf-408cac90a813@googlegroups.com...
>Shark8 wrote:
>> Turbo Pascal proved that a company could thrive by targeting 
>> small-businesses
>> and hobbyists with relatively cheap compilers.

>Well, yes, but back in 1983 the bar was set very low though.  Philipe 
>Kahn's
> TurboPascal only needed to be better than Microsoft's BASICA or
> GWBASIC .interpreters. (and better than Waterloo BASIC .interpreters.
> largely only on fellow-Canadian Commodore) and better than UCSD
> p-System Pascal's p-code .virtual machine..

That's not quite true, there were quite a few other options back then, 
including the $30 JRT Pascal and a variety of Ada subset compilers 
(including relatively inexpensive versions of Janus/Ada). Janus/Ada surely 
was a compiler-to-machine-code then (it always was, the interpreted version 
never left the lab).

What TurboPascal did better than anyone else is play the marketing game with 
a product that was "good enough". JRT for instance was well marketed but was 
rather limited. We (RRS = Janus/Ada) didn't do a very good job of the 
marketing game, and even if we had, I have to wonder if the product really 
was "good enough" (the cheap product probably wasn't, and the expensive one 
was too expensive -- we eventually got that right, but I think that was 
after the advent of TurboPascal).

In any case, the situation today is wildly different. As Dan'l said, many of 
the users bought Turbo Pascal because it was "good enough" and cheap. But 
today, one can get various compilers that are "good enough" and *free*. 
There is no real market for a $99 compiler today because someone can get 
something just as good for free -- why spend the money? (And the support for 
a $99 compiler necessarily has to be limited, meaning that it can't be much 
better than what you can get with a newsgroup like this one.)

The existence of GNAT effectively put RR Software out of business; a large 
part of our revenue came from being the lowest-cost Ada option, but of 
course one cannot compete with free. And we never had enough high-end 
business to survive on that alone. (That probably happened in part by trying 
to be the lowest-cost option, which caused reputational issues.)

I doubt that anyone could recapture the environment of the 1980s for any 
programming language -- a free option would appear way too quickly to pay 
back your investment.

                                                 Randy.

Re: Embeddinator-4000 begetting an Ada-cross-platform future?

[Bojan Bozovic]

On Friday, March 2, 2018 at 12:09:00 AM UTC+1, Randy Brukardt wrote:
> "Dan'l Miller" <optikos@verizon.net> wrote in message 
> news:e067f080-1eb6-4c23-82cf-408cac90a813@googlegroups.com...
> >Shark8 wrote:
> >> Turbo Pascal proved that a company could thrive by targeting 
> >> small-businesses
> >> and hobbyists with relatively cheap compilers.
> 
> >Well, yes, but back in 1983 the bar was set very low though.  Philipe 
> >Kahn's
> > TurboPascal only needed to be better than Microsoft's BASICA or
> > GWBASIC .interpreters. (and better than Waterloo BASIC .interpreters.
> > largely only on fellow-Canadian Commodore) and better than UCSD
> > p-System Pascal's p-code .virtual machine..
> 
> That's not quite true, there were quite a few other options back then, 
> including the $30 JRT Pascal and a variety of Ada subset compilers 
> (including relatively inexpensive versions of Janus/Ada). Janus/Ada surely 
> was a compiler-to-machine-code then (it always was, the interpreted version 
> never left the lab).
> 
> What TurboPascal did better than anyone else is play the marketing game with 
> a product that was "good enough". JRT for instance was well marketed but was 
> rather limited. We (RRS = Janus/Ada) didn't do a very good job of the 
> marketing game, and even if we had, I have to wonder if the product really 
> was "good enough" (the cheap product probably wasn't, and the expensive one 
> was too expensive -- we eventually got that right, but I think that was 
> after the advent of TurboPascal).
> 
> In any case, the situation today is wildly different. As Dan'l said, many of 
> the users bought Turbo Pascal because it was "good enough" and cheap. But 
> today, one can get various compilers that are "good enough" and *free*. 
> There is no real market for a $99 compiler today because someone can get 
> something just as good for free -- why spend the money? (And the support for 
> a $99 compiler necessarily has to be limited, meaning that it can't be much 
> better than what you can get with a newsgroup like this one.)
> 
> The existence of GNAT effectively put RR Software out of business; a large 
> part of our revenue came from being the lowest-cost Ada option, but of 
> course one cannot compete with free. And we never had enough high-end 
> business to survive on that alone. (That probably happened in part by trying 
> to be the lowest-cost option, which caused reputational issues.)
> 
> I doubt that anyone could recapture the environment of the 1980s for any 
> programming language -- a free option would appear way too quickly to pay 
> back your investment.
> 
>                                                  Randy.

Now my $0.02. The problem in Ada compilers and support for specific platform is Ada related problem, as C/C++ have many compilers available (MS, Intel, GCC, Clang/LLVM/XCode). Its simply due to bad reputation Ada got from the start, mostly from those with zilch experience with Ada, and this misinformation you all know well, dating from eighties. Thus I suppose its much easier to find qualified C/C++ programmer for a project, than Ada one, too, and you can't blame businesses from "going with the flow", they have to. AdaCore markets only to embedded and safety critical applications in automation, industry, transportation etc. That means little for ordinary applications where cost and time to market are more relevant, and even there Ada would do well, but it doesn't matter we know, it matters someone in charge of big business knows! On the other end there are Ada enthusiasts, and now I see someone would develop for Android and iOS with Ada, but is that enough to make new product for the market, be it FOSS or commercial one? For example, in my country no university offers Ada as part of CS curriculum. Much more needs to be done beyond what AdaCore and other embedded compiler developers do in terms of advocacy, so that more people use it and its more present in universities.

Re: Embeddinator-4000 begetting an Ada-cross-platform future?

[Dan'l Miller]

Cut & pasted from where?  I didn't cut & paste any of that.   I think you mean TL;DR, more than cut-&-pasted.

Re: Embeddinator-4000 begetting an Ada-cross-platform future?

[Luke A. Guest]

Dan'l Miller <optikos@verizon.net> wrote:
> Cut & pasted from where?  I didn't cut & paste any of that.   I think you
> mean TL;DR, more than cut-&-pasted.
> 

You mentioned cut n paste in your second message. And yeah, way too long;
dr.

Re: Embeddinator-4000 begetting an Ada-cross-platform future?

[Robert Eachus]

On Monday, February 26, 2018 at 12:06:19 PM UTC-5, Dan'l Miller wrote:
 
> This is tomorrow's carpe diem.  Seize it (or be a victim of natural selection's survival of the fittest).

Seize it yourself.  Pick a company with rights to an existing Ada compiler (I'd choose IBM's former Rational compiler) and a company interested in long-tail marketing (I'd choose Amazon) and convince them of a market for a $99 dollar individual compiler product.  It could support other languages, or interface cleanly with existing low-cost C or C++ compilers.

Succeed, and you may find yourself CEO of a joint venture.  If so, get an early product to market with little advertising, but with a commitment to an on-line update with no further costs for at least five years.  (And no cost to produce commercial products using the compiler.*  If you have to renew your license to maintain those products, the original license should contain a guaranteed renewal price.)

Once you are up and running with a decent marketshare, then you can pursue your grandiouse dreams.  Just do it in a way that keeps your successful business going, but allows new products to supplant it or whatever.  Just don't let those dreams interfere with servicing current customers.

* There is a non-trivial problem here, which you will have to address.  There will be (Ada) packages that interface to other, substantial products.  You want that, but the providers of that technology will need a way to match your efforts to their marketing strategy.  Take, for example, a statistics package.  You may provide the package spec as part of your product, but the package body (in effect) would come from elsewhere, for example SPSS or MATLAB, and require a (per CPU) license to use.  You might want to provide a non-proprietary body to the package, which might not run as fast, or contain fancy analysis tools to use on the program output.  Your choice.  You could even charge $19.95 for a license which allows programmers to produce licensing free products.

Re: Embeddinator-4000 begetting an Ada-cross-platform future?

[Dan'l Miller]

Robert Eachus wrote:
> Pick a company with rights to an existing Ada compiler (I'd choose IBM's former Rational compiler)

Rational's VADS Ada compiler does have a.app to serve as a basis of a modern deeply-reflective multi-stage-programming source-code-generator for Ada, as I mentioned in more detail along a thread of the “"functional" programming in Ada” posting.  Interesting.

Re: Embeddinator-4000 begetting an Ada-cross-platform future?

[alby.gamper]

On Saturday, March 10, 2018 at 3:45:23 AM UTC+11, Dan'l Miller wrote:
> Robert Eachus wrote:
> > Pick a company with rights to an existing Ada compiler (I'd choose IBM's former Rational compiler)
> 
> Rational's VADS Ada compiler does have a.app to serve as a basis of a modern deeply-reflective multi-stage-programming source-code-generator for Ada, as I mentioned in more detail along a thread of the “"functional" programming in Ada” posting.  Interesting.

Dear Dan'l Miller

I've taken a keen interest in seeing Ada used more in the UI/UX area, and to
that end have developed a language binding to WinRT (very similar to what
Kenny Kerr did with his c++/WinRT project) although this is not yet ready for
open source release, It is usable as a POC?

I did post a video some time ago, demonstrating the bindings and the Microsoft
Visual studio integration/toolchain. Have a look if you get time.

As far as I understand it, Embedinator-4000 targets the Mono runtime only
and is only possible because the native-mono-interop API supplies the required
functionality to do so. Microsoft's .Net runtime interop is not so friendly!
and the same thing cannot be done entirely in native code. It is possible, and
I have a worked example of a c++/native app starting up a Winforms app and
responding to events etc... But generating a language binding for ADA to .Net
or Mono would be no small task! (But then again neither was the WinRt Bindings)

I believe we (as in the Ada community, in the context of UI/UX development) 
Should start by supporting projects like Gnoga, AdaQt and my WinRT Bindings :-)
along with the integration of Ada into the mainstream IDE's

Alex

Re: Embeddinator-4000 begetting an Ada-cross-platform future?

[Dan'l Miller]

Alex wrote:
> I've ... developed a language binding to WinRT (very similar to what 
> Kenny Kerr did with his c++/WinRT project) although this is not yet ready for 
> open source release, It is usable as a POC

Awesome!  We very much look forward to it!  (Kenny Kerr's use of C++ value instances to represent WinRT-component types instead of actual C++ types representing WinRT-component types is likely something that you did not do in Ada.)  Did you generate the bindings automatedly from .winMD files as Kenny Kerr's work did via cppwinrt.exe?

> I did post a video some time ago, demonstrating the bindings and the Microsoft 
> Visual studio integration/toolchain. Have a look if you get time. 

I am very sorry that I missed that.  What is the URL to that video?  (My searches on YouTube are failing to find your video; btw, Ada and WinRT or Ada and UWP should be in the title for easy searching.  Perhaps it is not on YouTube.  Bing Video cannot find it either.)

Re: Embeddinator-4000 begetting an Ada-cross-platform future?

[alby.gamper]

On Wednesday, March 14, 2018 at 2:26:15 AM UTC+11, Dan'l Miller wrote:
> Alex wrote:
> > I've ... developed a language binding to WinRT (very similar to what 
> > Kenny Kerr did with his c++/WinRT project) although this is not yet ready for 
> > open source release, It is usable as a POC
> 
> Awesome!  We very much look forward to it!  (Kenny Kerr's use of C++ value instances to represent WinRT-component types instead of actual C++ types representing WinRT-component types is likely something that you did not do in Ada.)  Did you generate the bindings automatedly from .winMD files as Kenny Kerr's work did via cppwinrt.exe?
> 
> > I did post a video some time ago, demonstrating the bindings and the Microsoft 
> > Visual studio integration/toolchain. Have a look if you get time. 
> 
> I am very sorry that I missed that.  What is the URL to that video?  (My searches on YouTube are failing to find your video; btw, Ada and WinRT or Ada and UWP should be in the title for easy searching.  Perhaps it is not on YouTube.  Bing Video cannot find it either.)

Dear Dan'l

Yes I did generate the bindings from the winMD files, and the resulting Api
is a thin layer over the top of each of the winRT classes (each implemented
as a tagged type) Still a lot of work to do with mapping winRT generics to Ada.
But I believe the core functionality is usable.

If you search this newsgroup for "Ada Visual Studio Integration" you will
find my original post (But the url is https://youtu.be/e1J1Bc2I-R8  )

Note that the winRT bindings were done as part of my larger project, which is
to integrate gnat into Visual Studio, which my video demonstrates, along with
a project template that targets UWP. 

If you have any more questions, please feel free to ask

Alex

Re: Embeddinator-4000 begetting an Ada-cross-platform future?

[Dan'l Miller]

 Alex wrote:
> the resulting Api is a thin layer over the top of each of the winRT classes
> (each implemented as a tagged type) 

Oh, thank goodness!  Thank you very much!  Kenny Kerr's usage of value instances as type-ish stand-ins for types will likely be the cause of criticism/ridicule of C++/WinRT once its usage increases outside of Microsoft.  (Microsoft has a track-record of ridicule with 3 prior iterations:  1) Stanley Lippman's managed C++ (adding COM semantics intrinsically to C++ object model), 2) Herb Sutter's C++/CLI (C++ divided by CLI: grafting on C# semantics via ^-syntaxed not-quite-C++ C++-ish/C#-ish language strewn throughout C++, hence the pejorative “divided by” moniker), 3) C++/CX (C++ divided by CX:  analogous grafting of weird add-on language but for processor-native machine code instead of CLR), and now 4) weird not-types used as stand-ins for what the human brain thinks of as types hence again a grafted-on thing that doesn't feel at all like C++ (or any other strongly-type language's very-in-your-face type system).  Even if there exist downsides in your approach (e.g., a little more runtime overhead due to the tags' indirection), keeping the types as first-class citizens will be worth it.

> Still a lot of work to do with mapping winRT generics to Ada.

It appears that Kenny Kerr's work in C++/WinRT also is incomplete in that area, among others (e.g., Rx and Ix reactive & interactive extensions).  I believe these areas are deemphasized in C++/WinRT because they are deemed to have ISO C++ analogues to utilize instead (e.g., the standard library; RxCpp).  Do you really need to get the mapping of WinRT generics to Ada for an initial release of your WinRT-to-Ada binding generator?  I guess that begets the more-fundamental question:  how do you envision releasing your WinRT-to-Ada binding generator?  Open-source?  Proprietary commercial product?

Re: Embeddinator-4000 begetting an Ada-cross-platform future?

[alby.gamper]

On Thursday, March 15, 2018 at 2:24:51 AM UTC+11, Dan'l Miller wrote:
> Alex wrote:
> > the resulting Api is a thin layer over the top of each of the winRT classes
> > (each implemented as a tagged type) 
> 
> Oh, thank goodness!  Thank you very much!  Kenny Kerr's usage of value instances as type-ish stand-ins for types will likely be the cause of criticism/ridicule of C++/WinRT once its usage increases outside of Microsoft.  (Microsoft has a track-record of ridicule with 3 prior iterations:  1) Stanley Lippman's managed C++ (adding COM semantics intrinsically to C++ object model), 2) Herb Sutter's C++/CLI (C++ divided by CLI: grafting on C# semantics via ^-syntaxed not-quite-C++ C++-ish/C#-ish language strewn throughout C++, hence the pejorative “divided by” moniker), 3) C++/CX (C++ divided by CX:  analogous grafting of weird add-on language but for processor-native machine code instead of CLR), and now 4) weird not-types used as stand-ins for what the human brain thinks of as types hence again a grafted-on thing that doesn't feel at all like C++ (or any other strongly-type language's very-in-your-face type system).  Even if there exist downsides in your approach (e.g., a little more runtime overhead due to the tags' indirection), keeping the types as first-class citizens will be worth it.
> 
> > Still a lot of work to do with mapping winRT generics to Ada.
> 
> It appears that Kenny Kerr's work in C++/WinRT also is incomplete in that area, among others (e.g., Rx and Ix reactive & interactive extensions).  I believe these areas are deemphasized in C++/WinRT because they are deemed to have ISO C++ analogues to utilize instead (e.g., the standard library; RxCpp).  Do you really need to get the mapping of WinRT generics to Ada for an initial release of your WinRT-to-Ada binding generator?  I guess that begets the more-fundamental question:  how do you envision releasing your WinRT-to-Ada binding generator?  Open-source?  Proprietary commercial product?

Dear Dan'l

Regarding your first point, I take it you mean that you are not a fan of the
heavy use of C++ templates that Cpp/WinRt uses as an implementation. It does
make the code hard to read/understand/maintain (in my opinion)

WRT using Ada tagged types as an implementation, that was an obvious choice,
given that under GCC/GNAT C++ classes are equivalent to Ada Tagged types at the
ABI level and the binding needs to support client overriding semantics (ie
implementing a native/WinRT class and overriding a method/procedure)

WRT generics, in my current alpha non-release :-) Due to an issue. I believe
on my side, in getting dependent Ada packages (ie "limited with" and Ada generics
to work nicely) I have resorted to doing inline expansion of the required
code where needed.

When? I release sample code AND the underlying bindings/API you can analyse what
I have implemented wrt mapping WinRT to Ada and I will take on the communities
suggestion's on improvements. Note that I am far from being a "Language expert"
in either C++ or Ada, But I know that instinctively Ada is my language of choice
and I would like to see it as a general programming language (GPL) as it was
originally intended.

Alex

 

Re: Embeddinator-4000 begetting an Ada-cross-platform future?

[Dan'l Miller]

On Friday, March 16, 2018 at 4:55:56 AM UTC-5, alby....@gmail.com wrote:
> > Alex wrote:
> > > the resulting Api is a thin layer over the top of each of the winRT classes
> > > (each implemented as a tagged type) 

> On Thursday, March 15, 2018 at 2:24:51 AM UTC+11, Dan'l Miller wrote:
> > Oh, thank goodness!  Thank you very much!  Kenny Kerr's usage of value instances as type-ish
> > stand-ins for types will likely be the cause of criticism/ridicule of C++/WinRT once its usage
> > increases outside of Microsoft.

> Regarding your first point, I take it you mean that you are not a fan of the
> heavy use of C++ templates that Cpp/WinRt uses as an implementation. It does
> make the code hard to read/understand/maintain (in my opinion)

No, unfortunately, that is not what I am saying at all (although separately I have deep revulsion for Boost-esque metatemplate programming, sneaking functional-programming semantics in the backdoor via contortions of the C++ template engine).  What I am saying is much worse, as measured by eye-popping inane contortions of OO in ways that most strongly-typed-OO-knowlegdable people (in any language) would consider as inappropriate:  

https://github.com/Microsoft/cppwinrt/blob/master/Docs/Migrating%20C%2B%2B%20CX%20source%20code%20to%20C%2B%2B%20WinRT.md

<background>
Although the readers in this forum might not be the Nth degree of C++ experts, readers here are even less likely to recognize the /CX (divided by CX) and /CLI (divided by CLI) proprietary extensions to C++, as utilized (as C++/CX here, not C++/CLI) in the WWW-page above from Kenny Kerr et. al.  (Btw, /CX generates processor-native machine code; /CLI generates .NET CLR bytecode.)  In a nutshell, any time you see ^ as a suffix on a type, the ^ is playing much the same role as * (pointer) in standard C & C++, but grafting on an entirely different object model from ATL/COM Microsoft technologies.  ATL/COM's OO concepts vaguely resemble C++'s (or Ada's) processor-native OO object model, but are kept as entirely separate & disjoint as Objective-C runtime is from C++ in Apple's/Clang's/GCC's Objective-C++, but with still different semantics than either standard C++'s (or Ada's) processor-native object model or than Objective-C's runtime object model.  What those different semantics are is not germane here; suffice it to say, one must keep standard C++ instances, pointers, references, and collections (e.g., with * and & syntax) entirely away from /CX instance, references, and collections (i.e., clearly demarcated with ^-syntaxed WinRT-component references) and, except for some very limited forms of containment, one must keep standard C++ classes and structs almost entirely away from WinRT-component classes (i.e., as clearly demarcated by the “ref class” instead of “class” declaration.  Okay, now the reader has just enough background to read that URL's WWW-page.
</background>

Please take a look at the before & after transformation of source code in that WWW-page linked above to see how C++/CX code is to be transformed/rewritten as C++/WinRT source code.  Note that /CX (true-)types known to the compiler are transformed to value-semantics instances of (nontemplate) classes/structs so that the compiler no longer recognizes them as types at all!  As instances they remain a little bit strongly typed, but not things that are themselves (WinRT-component) instances of that pseudo-type record-instance (to use Ada's terminology) are obviously not instances of that pseudo-type to the compiler because the compiler knows types as types, not pseudo-types as types.  This contortion of data to represent types in ways that the compiler does not recognize as a type at all is what I am referring to.  The party-line claim is that this bizarre contortion is absolutely demanded by the problem-space as the only practical solution in C++2017.  Your VisualAda work will refute this (false) claim (because anything that you designed in Ada as true tagged types known as types to the Ada compiler has corresponding C++2003-era (or even C++2011 or C++2014 or C++2017) representations of a directly analogous design.  Thank you very very much!  Your work is not only a breakthrough for Ada, but for humankind in general spilling far beyond Ada, most notably in C++ by the corresponding implied C++ design analogous to your Ada tagged-type design.

> WRT using Ada tagged types as an implementation, that was an obvious choice,
> given that under GCC/GNAT C++ classes are equivalent to Ada Tagged types at the
> ABI level and the binding needs to support client overriding semantics (ie
> implementing a native/WinRT class and overriding a method/procedure)

I wholeheartedly agree.

> WRT generics, in my current alpha non-release :-) Due to an issue. I believe
> on my side, in getting dependent Ada packages (ie "limited with" and Ada generics
> to work nicely) I have resorted to doing inline expansion of the required
> code where needed.

Please keep up  the good work!  Also, please consider posting snippets of problematic limited-with & generics code in Ada to comp.lang.ada to see whether anyone can add further revelations.  Because you have a code-generator at the heart of VisualAda's WinRT/UWP bindings, generated non-generic Ada source code •might• be superior to generating generic-based code that needs its own compiler-based generic generation.  So you should consider the possibility that you might have the best-performing solution right now, either at run-time or build-time or both.

> When? I release sample code AND the underlying bindings/API you can analyse what
> I have implemented wrt mapping WinRT to Ada and I will take on the communities
> suggestion's on improvements. Note that I am far from being a "Language expert"
> in either C++ or Ada, But I know that instinctively Ada is my language of choice
> and I would like to see it as a general programming language (GPL) as it was
> originally intended.

I am sure that I & some others will look lovingly on anything that gets the job done.  I think you can declare this as a 0.1 release and that the 1.0 release's API/ABI/interface-façade/personality presented to app-domain code is likely to drastically change.

Re: Embeddinator-4000 begetting an Ada-cross-platform future?

[Ivan Levashev]

27.02.2018 0:06, Dan'l Miller пишет:
> Although none of this supports Ada at this time, let's walk along a
> path of the present (0) and emerging (1 through 3) and a potential
> future (4 through 8) together.

Before reading about minor miracles, I would recommend reading 
Release-to-Release Binary Compatibility in SOM. It has a nice table, and 
most noted are still behind. Those who crafted this table probably did 
not want to make a map being valid for 20 years, but we are still there, 
like in 1408 movie.

If you take a closer look at WinRT in C++, you'll see that it is not 
evolved much compared to COM, which is even not present in the table.

Public constructors in non-sealed WinRT classes are prohibited to 
prevent inheritance. Inheritance would raise issues. SOM was solving 
these issues since 1991. Objective-C 2.0 started to solve these issues 
since 2006, but not as good as SOM did. WinRT still got no right to be 
present in this table.

VM's call conventions are not quite appropriate for native programming 
languages. Double JNI is much more overhead than method call in SOM or 
Objective-C. So this approach is also quite limited.

We are still there, like in 1408 movie. This is it, and everything else 
is a hype.

Table mentions Sun OBI, SGI Delta/C++, and I've read papers on them. 
Those times people were really experimenting, nowadays this engineering 
discipline is getting forgotten. So we might not be stuck in eternal 
1996, but even worse, rolling back to pre-1991.

Best Regards,
Ivan Levashev,
Barnaul

--
If you want to get to the top, you have to start at the bottom

Re: Embeddinator-4000 begetting an Ada-cross-platform future?

[Dan'l Miller]

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

Because this is along the threads of a posting about bringing •compile•-time ••source-code projections•• 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 something to the effect of:  because of lack of much progress on ABI-based extensibility without additional (re)compilation of the app's original source-code (or the API declarations on which the app's original source code relies), interest 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, Apple 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) existing in a few nooks & crannies of the industry (e.g., MIPS ISA in a few network processors and in PRChina's Loonson/Godson processor research; OS/2 still available for purchase at an IBM partner).

But such ABI-based extensibility without (re)compilation is effectively a luxury that even the most-multi-billion-dollar corporations nowadays are unwilling 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 significant •increase• in churn in the APIs at the source-code-of-SDKs level.  Hence Apple's OSes have not yet even achieved API/source-code stability, let alone ABI discipline.  Microsoft is in an even weirder situation with ever-present presumption (and release of SDK previews) for a Windows 10 Mobile OS without any new phones or non-Surface-with-less-than-full-fledged-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 which 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 rather Google is apparently pursuing a replacement Fuscia OS for both Android and ChromeOS that would serve both marketspaces.  Samsung's Tizen is apparently seeking an eventual de-emphasis (or divorce) from Android (perhaps at the same time as Google's rollout of Fuscia OS).  So clearly Apple, Microsoft, Google, and Samsung have their OS/SDK hands quite (over-)full just getting 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 enough to build out all this new OS technology for SDK source-code compilation 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 languages (i.e., Swift & Objective-C on Apple OSes, Java on Android & ChromeOS, C# & F# & C++/CX on Microsoft OSes).  They apparently have no time or funding for SOM-esque luxuries at the ABI level.

Taking all that as the inventory of (even the bleeding edge of) the state-of-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-by-CX C++ for that matter) to achieve at least 2nd-class-citizen residency on the UI/UX code of Apple's, Microsoft's, and Google's OSes, instead of being forever relegated to the dungeon of backend libraries without UI/UX responsibilities.  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-based language-projection of SDK API plus Xamarin-provided glue code between app & OS's (fluid) ABI for each release.  (Tizen already has embraced standard C++, as I understand it, so interworking with Ada has somewhat more hope for less barrier to entry sooner.)  Language-projecting at the source-code level of an SDK and then compiling is so much more practical at this inventorying of the state of the art of the industry than wishing for (and worse, 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.