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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: border2.nntp.dca.giganews.com!nntp.giganews.com!goblin3!goblin1!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Your wish list for Ada 202X Date: Thu, 17 Apr 2014 21:54:27 +0200 Organization: cbb software GmbH Message-ID: <1qgwlpbj8x1pq$.de25lxbxr7w8$.dlg@40tude.net> References: <7f1c01c5-3563-4b94-9831-152dbbf2ecdc@googlegroups.com> <1cdsyxjzsfgzm.1synpaujysv21$.dlg@40tude.net> <1aa804jg9qq4o$.wdiq33yo621l.dlg@40tude.net> <1w6eh0aiksmdh$.1h16p7y0b8c6h.dlg@40tude.net> <17twpp4p8u7o$.1idvzaaio4f3t$.dlg@40tude.net> <16388p09ph28u$.1mglp0rm7pli9$.dlg@40tude.net> <9cm2e094hvj7.sj0t2sh2komn.dlg@40tude.net> <1wchtiw4r35px.1pwedxqesqlr4.dlg@40tude.net> <1239ezez4bgf7.e2ihtjo019ka.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: AuYlnUSfTZrfhAkRjyySpQ.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: number.nntp.dca.giganews.com comp.lang.ada:185790 Date: 2014-04-17T21:54:27+02:00 List-Id: On Thu, 17 Apr 2014 12:29:29 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:1239ezez4bgf7.e2ihtjo019ka.dlg@40tude.net... >> On Wed, 16 Apr 2014 16:53:05 -0500, Randy Brukardt wrote: >> >>> "Dmitry A. Kazakov" wrote in message >>> news:1wchtiw4r35px.1pwedxqesqlr4.dlg@40tude.net... >>> ... >>>>> The reason here is that maintainers need to be free to ADD new >>>>> operations/entities without changing the behavior of any pre-existing >>>>> client (which necessarily does not use those new operations/entities). >>>> >>>> Again, no difference between SD and MD. If you add a new primitive >>>> operation (not override an existing one), there cannot be any effect on >>>> the clients because they did not use the operation. >>> >>> But that's not now and never has been true. Why? Because the new operation >>> can have the same name as some existing operation, and the entire point of >>> this discussion is that preference rules in overloading resolution have >>> potentially bad effects in such cases. >> >> No, it can have the same name only if the signature is different. That >> would be overloading, thus whatever rules of preference for MD are, they >> would not apply. >> >> If you want to say that overloading is a can of worms. Yes it is. But that >> has nothing to do with MD vs. SD and ambiguity resolution there. > > Well, talking about Ada, there is only overloading resolution. The same > rules apply to all calls, there is nothing special about primitive > operations. One could certainly imagine other rules, but they wouldn't fit > into the framework of Ada resolution without a lot of reworking. The point I made was about possibility to have preference rules for MD without "bad effects." In order to disprove it you should present a case showing that no set of rules could prevent such effects. Regarding "reworking" there is no reworking because MD is non-existent in Ada. > Like a lot of your ideas, they would make much more sense in a new language > rather than in the context of the existing Ada language. This again requires a proof, which would be quite difficult to make, because the only reason why MD or other sound type construct would be impossible in Ada then due to some fatal design errors in the language core. I trust Ada design most of the time. It surprises me that you seemingly do not. But then you should present these alleged design faults. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de