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!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!newsfeed.fsmpi.rwth-aachen.de!reality.xs3.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Your wish list for Ada 202X Date: Tue, 15 Apr 2014 16:27:05 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: 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> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1397597226 3275 69.95.181.76 (15 Apr 2014 21:27:06 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 15 Apr 2014 21:27:06 +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: news.eternal-september.org comp.lang.ada:19321 Date: 2014-04-15T16:27:05-05:00 List-Id: "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". (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). 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). Otherwise, maintenance is just a turkey shoot in which you really have no idea what will happen -- deadly in large systems, especially with reused code that's not in your control (think of a new version of GTK or Claw). OTOH, if maintainers *change* an operation/entity, then the language can (and should) provide no assurances. Randy.