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 2002:a24:295:: with SMTP id 143-v6mr1157241itu.55.1521214521574; Fri, 16 Mar 2018 08:35:21 -0700 (PDT) X-Received: by 2002:a9d:5:: with SMTP id 5-v6mr112565ota.0.1521214521395; Fri, 16 Mar 2018 08:35:21 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!weretis.net!feeder4.news.weretis.net!news.roellig-ltd.de!open-news-network.org!peer01.am4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!r195-v6no591258itc.0!news-out.google.com!a25-v6ni905itj.0!nntp.google.com!e10-v6no585936itf.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 16 Mar 2018 08:35:21 -0700 (PDT) In-Reply-To: <93b2ceb2-0beb-47cf-a9f1-59ac7e81e052@googlegroups.com> 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> <92b09533-40a2-4a91-a9bc-7b6eddb3e3a1@googlegroups.com> <1f3db512-b336-47aa-a3de-1f3771c15d75@googlegroups.com> <93b2ceb2-0beb-47cf-a9f1-59ac7e81e052@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <77063005-bf79-4f34-ad91-35ce1f682c7e@googlegroups.com> Subject: Re: Embeddinator-4000 begetting an Ada-cross-platform future? From: "Dan'l Miller" Injection-Date: Fri, 16 Mar 2018 15:35:21 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Body-CRC: 341415009 X-Received-Bytes: 8255 Xref: reader02.eternal-september.org comp.lang.ada:51029 Date: 2018-03-16T08:35:21-07:00 List-Id: 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 c= lasses > > > (each implemented as a tagged type)=20 > 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 d= oes > 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 f= unctional-programming semantics in the backdoor via contortions of the C++ = template engine). What I am saying is much worse, as measured by eye-poppi= ng inane contortions of OO in ways that most strongly-typed-OO-knowlegdable= people (in any language) would consider as inappropriate: =20 https://github.com/Microsoft/cppwinrt/blob/master/Docs/Migrating%20C%2B%2B%= 20CX%20source%20code%20to%20C%2B%2B%20WinRT.md Although the readers in this forum might not be the Nth degree of C++ exper= ts, 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 byte= code.) In a nutshell, any time you see ^ as a suffix on a type, the ^ is p= laying 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 O= O 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 diffe= rent semantics are is not germane here; suffice it to say, one must keep st= andard C++ instances, pointers, references, and collections (e.g., with * a= nd & syntax) entirely away from /CX instance, references, and collections (= i.e., clearly demarcated with ^-syntaxed WinRT-component references) and, e= xcept 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 =E2=80=9Cref class=E2=80=9D instead of =E2= =80=9Cclass=E2=80=9D declaration. Okay, now the reader has just enough bac= kground to read that URL's WWW-page. Please take a look at the before & after transformation of source code in t= hat WWW-page linked above to see how C++/CX code is to be transformed/rewri= tten as C++/WinRT source code. Note that /CX (true-)types known to the com= piler are transformed to value-semantics instances of (nontemplate) classes= /structs so that the compiler no longer recognizes them as types at all! A= s instances they remain a little bit strongly typed, but not things that ar= e themselves (WinRT-component) instances of that pseudo-type record-instanc= e (to use Ada's terminology) are obviously not instances of that pseudo-typ= e to the compiler because the compiler knows types as types, not pseudo-typ= es as types. This contortion of data to represent types in ways that the c= ompiler 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 VisualA= da 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 correspo= nding C++2003-era (or even C++2011 or C++2014 or C++2017) representations o= f 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 bey= ond Ada, most notably in C++ by the corresponding implied C++ design analog= ous to your Ada tagged-type design. > WRT using Ada tagged types as an implementation, that was an obvious choi= ce, > 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 (i= e > 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 beli= eve > 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 p= roblematic limited-with & generics code in Ada to comp.lang.ada to see whet= her anyone can add further revelations. Because you have a code-generator = at the heart of VisualAda's WinRT/UWP bindings, generated non-generic Ada s= ource code =E2=80=A2might=E2=80=A2 be superior to generating generic-based = code that needs its own compiler-based generic generation. So you should c= onsider the possibility that you might have the best-performing solution ri= ght now, either at run-time or build-time or both. > When? I release sample code AND the underlying bindings/API you can analy= se what > I have implemented wrt mapping WinRT to Ada and I will take on the commun= ities > suggestion's on improvements. Note that I am far from being a "Language e= xpert" > 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=C3=A7ade/personality presented to app-domain= code is likely to drastically change.