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.1 required=5.0 tests=BAYES_00, PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4 Path: border2.nntp.ams2.giganews.com!backlog4.nntp.ams3.giganews.com!backlog4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!nntp.giganews.com!news.mixmin.net!newsfeed.fsmpi.rwth-aachen.de!reality.xs3.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Augusta: An open source Ada 2012 compiler (someday?) Date: Mon, 24 Mar 2014 16:21:20 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <1f0a85a6-ea4d-4d30-8537-0ce9063f992a@googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1395696081 20972 69.95.181.76 (24 Mar 2014 21:21:21 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 24 Mar 2014 21:21:21 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Original-Bytes: 5440 Xref: number.nntp.dca.giganews.com comp.lang.ada:185328 Date: 2014-03-24T16:21:20-05:00 List-Id: "J Kimball" wrote in message news:lgopof$unl$1@loke.gir.dk... > On 03/20/2014 06:15 PM, Randy Brukardt wrote: >> "J-P. Rosen" wrote in message >> news:lgeh3m$gqq$1@dont-email.me... >>> Le 20/03/2014 11:23, Lucretia a écrit : >>>>> I am not as naive as I probably sound. I fully understand that such a >>>>>> project is massive and not likely to actually ever be completed. >>>> As long as you don't expect all the annexes, I don't see why not. >>>> >>> All those who have been involved in an Ada compiler will tell you that >>> it is a lot more difficult than it appears, unless you stick to the >>> Pascal subset and don't care for validation. >>> >>> In the early days of Ada, we have seen compilers announcing proudly that >>> they passed 95% of the validation and that delivery was expected in a >>> few weeks - they never succeeded to pass the remaining 5%. >>> >>> For example, and as a test, make sure you are able to understand the >>> implications of 4.3.3 (a nightmare for code generation), or 13.14, or >>> 3.10.2(3/2)... >> >> Heck, we (the ARG) aren't quite sure how you implement accessibility >> checks >> for Ada 2005 and Ada 2012 (see AI12-0016-1 for some thinking); you could >> waste a lot of time trying to figure that out. And like J-P says, a 95% >> solution isn't good for much -- the real solution is 95% different. :-) >> >> It's for good reason that 3.10.2 is informally named "The Heart of >> Darkness"! ;-) > > You are listening to what you're saying aren't you? I know we joke about > things > when we're uncomfortable with them. The people writing the rules don't > know how to enforce them? There's an actual part of the manual that has a > nick name > "The Heart of Darkness!". Your own compiler can't even compete because of > the labyrinth of rules. Not really. My compiler can't compete because I'm a lousy businessman and to a lesser extent because I'm rather burned out. Some of these corner cases (especially "the Heart of Darkness") are obscure corners of the language of little interest to anyone. Until you try to get rid of them, and then the safety argument rears up (dangling pointers are a scourge). > Ada has become the American tax code. It's becoming abundantly clear > that there has to be a massive break in backward compatibility in the next > revision of the language that makes writing compilers easier, not just > keeping > AdaCore in business, but breaking out of the framework of Ada 95. I'd be in favor of that, but I'm dubious that the customers that support Ada would want to make that sort of change. And if the customers don't come along, then there is little energy for anything to happen. After all, most hobbyest driven projects tend to wane after a couple of years, and that's not going to work for the sorts of long-lived projects that Ada is best at. > We find ourselves discussing this regularly in #ada on Freenode. Many of > us > see Ada as a sinking ship because of all its baggage. The ideals are > strong, > but the implementation is losing us. I could see some relatively small tweaks, but I doubt that would help implementation effort much. In particular, one of the nastiest things is type resolution. But the part of type resolution that is hard is the ability to overload on result types. (That's not allowed by C++, for instance.) But a large part of the elegance and ease-of-use of operators comes from that ability. Taking it away would prevent a lot of common techniques (for instance, it's what allows overloading of enumeration literals). I'd be more interested in regularizing some of the rules (such as making objects overloadable) -- but I doubt that would have any positive impact on the effort to implement Ada. One could try removing/altering large but not frequently used areas -- fixed point, tasks, discriminant-dependent components come to mind -- but for each one, you'd lose a bunch of Ada fans. > I surely need to review the AIs for the next revision to see what's > happening. Nothing to speak of yet; too soon after Ada 2012 to do anything formally. We're just gathering ideas at this point. Randy.