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 X-Received: by 10.58.178.81 with SMTP id cw17mr2967984vec.37.1397634765215; Wed, 16 Apr 2014 00:52:45 -0700 (PDT) Path: border2.nntp.dca.giganews.com!nntp.giganews.com!cm18no3385844qab.0!news-out.google.com!dz10ni11242qab.1!nntp.google.com!peer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!newsfeed1.swip.net!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Your wish list for Ada 202X Date: Wed, 16 Apr 2014 09:52:44 +0200 Organization: cbb software GmbH Message-ID: <1wchtiw4r35px.1pwedxqesqlr4.dlg@40tude.net> References: <7f1c01c5-3563-4b94-9831-152dbbf2ecdc@googlegroups.com> <8bhozh836pyt$.1qctlysud0s2q$.dlg@40tude.net> <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> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: G+aXx1XI67D34t54ibhUPQ.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 X-Received-Bytes: 4985 X-Received-Body-CRC: 1913539371 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Xref: number.nntp.dca.giganews.com comp.lang.ada:185767 Date: 2014-04-16T09:52:44+02:00 List-Id: On Tue, 15 Apr 2014 16:27:05 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:f2mjap6bd64o$.1kk55f3m1qbn1$.dlg@40tude.net... >> On Mon, 14 Apr 2014 18:39:24 -0500, Randy Brukardt wrote: >> >>> "Dmitry A. Kazakov" wrote in message >>> news:9cm2e094hvj7.sj0t2sh2komn.dlg@40tude.net... >>>> On Fri, 11 Apr 2014 16:44:13 -0500, Randy Brukardt wrote: >>>> >>>>> "Dmitry A. Kazakov" wrote in message >>>>> news:16388p09ph28u$.1mglp0rm7pli9$.dlg@40tude.net... >>>> >>>>>> Your example refers to overloading possible for operations on >>>>>> unrelated >>>>>> types. I don't see how this is scenario could be possible for a >>>>>> primitive >>>>>> MD operation. One of the requirements put on MD is that *all* >>>>>> combinations >>>>>> of tags up to the root of the inheritance tree be defined and checked >>>>>> at >>>>>> compile time. This requirement automatically precludes appearance of C >>>>>> from >>>>>> air. It cannot be primitive and thus the preference rules would not >>>>>> apply >>>>>> to it. >>>>> >>>>> Doesn't matter. First, you'd have to prevent adding or removing new >>>>> primitive operations to a hierarchy. That seems like a nasty >>>>> limitation. >>>> >>>> What? This limitation is with us since Ada 95! You cannot add a >>>> primitive >>>> operation after the freezing point in Ada. You cannot remove a primitive >>>> operation at all. >>> >>> This is an issue with program maintenance, not with an unchanging >>> declaration -- so freezing is completely irrelevant. If someone decides >>> there is a need to add a primitive operation to the root (for instance), >>> then a preference rule towrd the root could potentially silently change >>> the >>> behavior of a otherwise tested/proved program. That's the sort of thing >>> that >>> needs to be prevented, lest maintenance become too dangerous to allow in >>> existing systems. >> >> It is not prevented now and cannot be prevented in the future. If you >> change the package specification, which is the only way to add an >> operation >> you potentially change anything. This requires recompilation of all >> clients, which is OK, as you said earlier. Thus the problem does not >> exist. > > (A) we're specifically talking about a single addition or deletion, *not* a > general "change". And how is it different from single dispatch? Let you override f in S. Then f(X), given X is of S, will call to the new body. > (B) Of course we're changing the specification and recompiling. But we don't > want the same client code to mean something different after that > recompilation without detection -- in the case of a single addition or > deletion (again, *not* a change). It must mean something different. That was the *purpose* of the change to make the client code mean it different *when* the clients use the types and operations for which the change was made. > 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. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de