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-FeedAbuse: http://nntpfeed.proxad.net/abuse.pl feeded by 78.192.65.63 Path: border2.nntp.dca.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!eu.feeder.erje.net!proxad.net!feeder1-2.proxad.net!nntpfeed.proxad.net!news.muarf.org!news.ecp.fr!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: Tue, 25 Mar 2014 15:47:35 -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 1395780456 15086 69.95.181.76 (25 Mar 2014 20:47:36 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 25 Mar 2014 20:47:36 +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: number.nntp.dca.giganews.com comp.lang.ada:185344 Date: 2014-03-25T15:47:35-05:00 List-Id: wrote in message news:alpine.DEB.2.10.1403251025030.10474@debian... >On Mon, 24 Mar 2014, Randy Brukardt wrote: > >> "J Kimball" wrote in message >> news:lgopof$unl$1@loke.gir.dk... > >>> 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. > >What about moving not-so-often used language features into an annex? > >Thus, if your customers demand the feature, you are allowed to support it. >Furthermore, anyone supporting that feature would do so so in a completely >compatible way. > >But if you don't want to support that feature, or you can't for some >reason, you are allowed to support Ada 20XY without that annex. This would work, but it wouldn't have any effect on simplifying the Standard (since the wording in the Standard would have to be prepared to handle the feature -- that's especially likely to be an issue for things like interfaces, which have an effect on virtually every definition in the Standard). And if one doesn't simplify the Standard, it's fairly unlikely that you're actually going to simplify implementation that much. >As an example, I would consider interfaces. The support for multiple >inheritance from "interface" could could be moved into an annex, and thus >become optional for the language implementer. The key-word "interface" >should remain reserved, for compatibility reasons. Right. But as always, the difficulty would be agreeing on what goes into such an index. I'd vote for interfaces and anonymous access types, but I'm sure the fans of those features would not be very happy. And they probably have some features that I find important that they think ought to be in the junk bin. You'd be amazed at how hard it is to even move a feature into Annex J (Obsolescent Features), even those are required to be implemented. I'm still hearing flack about the decision to move aspect pragmas there, even though entity-specific pragmas was one of worst ideas ever known to mankind. :-) Randy.