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

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

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.