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: border1.nntp.dca3.giganews.com!backlog3.nntp.dca3.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!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: Fri, 11 Apr 2014 16:44:13 -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> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1397252655 1743 69.95.181.76 (11 Apr 2014 21:44:15 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 11 Apr 2014 21:44:15 +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 X-Original-Bytes: 5294 Xref: number.nntp.dca.giganews.com comp.lang.ada:185686 Date: 2014-04-11T16:44:13-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:16388p09ph28u$.1mglp0rm7pli9$.dlg@40tude.net... > On Thu, 10 Apr 2014 17:39:39 -0500, Randy Brukardt wrote: > >> "Dmitry A. Kazakov" wrote in message >> news:17twpp4p8u7o$.1idvzaaio4f3t$.dlg@40tude.net... >>> On Wed, 9 Apr 2014 22:28:36 -0500, Randy Brukardt wrote: >> ... >>>>> Ada has no support for dynamic linking anyway, so it is how it is >>>>> right >>>>> now. Introducing MD won't make bad any worse. >>>> >>>> MD isn't the problem; preference rules are the problem. >>> >>> That requires a proof which shows that no set of rules can exist that >>> fulfills the requirements X, Y, Z. So far it is word against word. Not >>> even X, Y, Z is formulated. >> >> Actually, there was such a formal proof constructed during the design of >> Ada >> 9x. Unfortunately, that's pretty much all I remember about it, so it's >> not >> much help in this discussion. >> >> But it's quite clear that (sane) preference rules cause Beaujolias. >> >> Consider an expression node for which two choices (let's call them A and >> B) >> remain after eliminating obvious mismatches. (This situation can be >> common >> when literals are involved, as they match so many types). Ada of course >> makes the expression illegal in this case, specifically to avoid >> Beaujolias. >> >> But let's consider a preference rule instead. The rule choses A over B, >> and >> then the program is legal and runs. >> >> Now consider adding another operation C in some package that's referenced >> by >> the semantic closure ("with" in Ada) of our expression. Assume that C >> also >> is a possible choice for our expression node. If the preference rule >> picks C >> rather than A (or picks B for that matter), then we have the classic >> Beaujolias scenario when a legal program does something different because >> an >> operation is added to an unrelated package. > > 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. Second, you can introduce a new primitive operation by withing ["ripple"] or using ["Beaujolias"] an existing package that wasn't previously part of the client. Introducing an otherwise unused package ought not change the behavior of a client. > This requirement is actually a problem of MD, I don't know how to solve, > i.e. how to stretch a hierarchy across several packages. Let two packages > define two types P and Q and a cross operation F between. When in a third > package R gets derived from P, then how and where we define F for R and Q, > provided this third package may know nothing about the package of Q. I suppose if you could actually solve such a problem without introducing crazy usage requirements, you could get the same effect as a preference rule safely. But I'd guess (and I admit it is a guess) that the problems are essentially the same and the fact that one clearly fails the test means that the other would clearly fail the test as well. Randy.