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!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: some trivial questions? Date: Wed, 22 Nov 2017 09:42:58 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <6a5368c5-f015-4dcb-9291-e77b40fa1bf1@googlegroups.com> NNTP-Posting-Host: MyFhHs417jM9AgzRpXn7yg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 X-Notice: Filtered by postfilter v. 0.8.2 Content-Language: en-US Xref: feeder.eternal-september.org comp.lang.ada:49050 Date: 2017-11-22T09:42:58+01:00 List-Id: On 22/11/2017 01:56, Randy Brukardt wrote: > "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. The idea which is floating around for a long while is to introduce a more general type system in which present standard would be expressed as-is without any changes. Compatibility problems arise when doing incremental changes at the same abstraction level, Once you move up or down there is no problem anymore. > 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.) That is exactly the solution like above but at a narrower scale - you can have operators either visible or not. The method was actually not to decide that and simply implement both variants. The first variant was made default the second received the syntax "use type". At a larger scale the problem is that the language may fall apart if we keep on adding arbitrary syntax constructs like "use type". This is why it must be one major change. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de