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!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.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: some trivial questions? Date: Tue, 21 Nov 2017 18:56:27 -0600 Organization: JSA Research & Innovation Message-ID: References: <6a5368c5-f015-4dcb-9291-e77b40fa1bf1@googlegroups.com> Injection-Date: Wed, 22 Nov 2017 00:56:27 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="18678"; mail-complaints-to="news@jacob-sparre.dk" 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.7246 Xref: feeder.eternal-september.org comp.lang.ada:49042 Date: 2017-11-21T18:56:27-06:00 List-Id: "Dmitry A. Kazakov" wrote in message news:ov0v0f$663$1@gioia.aioe.org... > On 2017-11-20 23:03, Randy Brukardt wrote: ... >>> Sure, nothing useful going to happen for Ada. >> >> I agree that this is annoying. The problem is that an incompatible Ada >> would >> be starting over from scratch (as existing libraries would not be >> usable), > > There are lots of changes which can be made while keeping everything > compatibility. The problem is with small increments. That does not work. > If we want to do something real this must be done in one large jump. This > worked for Ada 95 once, it can work again. The problem with this sort of thing is *proving* that the changes are in fact compatible. In the absence of that, the forces of FUD would have a field day, and it would be very hard to convince people that there was no problem. That has plagued every Ada update since Ada 95. (Did you know that Ada 95 was supposed to have a mechanism where operators were always visible? That got killed off in favor of "use type" in part because the Ada 9x team couldn't convince the MRT that there wasn't any possible incompatibility.) Similar issues have occurred for every version of Ada since. (Attempts to fix the problem of tagged derived types in generic units among others have died because of compatibility concerns. Similarly, my attempt to allow untagged type declarations in the private part of protected types seems to have died for that reason, even though it's not possible for there to be an incompatibility [I think]. I think there is a currently open AI that probably will be eventually dropped because of compatibility concerns, rather than making it into Ada 2020. And so it goes...) Of course, a true proof is hard to do when the rules are primarily modeled in English as opposed to some formal system. So this is a very hard problem twice over. Randy.