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 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: State of the compiler market Date: Tue, 28 Feb 2017 14:51:12 -0600 Organization: JSA Research & Innovation Message-ID: References: <1813789782.509760763.093426.laguest-archeia.com@nntp.aioe.org> <87varxjouh.fsf@nightsong.com> NNTP-Posting-Host: rrsoftware.com X-Trace: franka.jacob-sparre.dk 1488315073 29833 24.196.82.226 (28 Feb 2017 20:51:13 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 28 Feb 2017 20:51:13 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:33435 Date: 2017-02-28T14:51:12-06:00 List-Id: "Paul Rubin" wrote in message news:87varxjouh.fsf@nightsong.com... > "Randy Brukardt" writes: >> I think a better approach would be to convince an existing Ada 95 >> implementation to go open source and then enhance that to do the things >> desired (Ada 2020 support, etc.). > > 1. I found a few google hits for Ada 2020 but nothing like a concrete > list of changes or proposals. Just "ARG is working on it". Is there > anything public? The date isn't even firm yet, so it's rather early to read too much into that. But all of the work is publically available on Ada-auth.org. Summaries and the like will likely wait until wee get closer to a deadline (who can tell today if the parallel block and loop stuff will get mature enough to include??). > 2. Is there really serious difficulty extending an Ada 95 compiler to > handle Ada 2012? Everything is possible with software, but how much effort are you willing to put in? There aren't any major breakages, but there's a lot of new stuff to integrate. It took me a month to get the grammar (alone) to be usable and not break anything already implemented. > I'm a FOSS supporter myself, but in the case of an alternate Ada > implementation, I'd think the most interesting possibility would be for > someone (maybe Adacore) to team up with the CompCert guys and make a > verified Ada compiler. > >> Figuring out Ada resolution rules, Ada tasking, the Ada optimization >> rules, and many other things will sap anyone of energy long before >> they complete it. > > How bad is this really? Is the ARM that hard to read (I've never > tried)? On the surface Ada doesn't seem particularly harder than Java, > and certainly easier than C++. But I haven't gone into the deeper > corners or used it much. Ada resolution is unique in that the type of anything can determine the type of an expression. This allows overloading on function results (only) which is generally not allowed in other languages. But it also can lead to expressions that are very complex to figure out the types: F1.all := F2 + F3; All of these can be overloaded (as well as "+", which acts like a function for this purpose), and if there is a unique solution, the Ada compiler has to find it. I often find bizarre (to me) special cases in the code of Janus/Ada, and I often try to get rid of them. And then most of the time, I have to put them back because they're needed for some wacky ACATS test (or old user bug report). We had 14 man-years of development into our Ada 83 compiler; while I don't have an exact number for our Ada 95 compiler, it has to be double that. Some of it clearly came from the much smaller hosts of the era, but most of it is just Ada being big. Randy.