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: border1.nntp.dca1.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Georg Bauhaus Newsgroups: comp.lang.ada Subject: Re: Functions vs constants Date: Thu, 24 Jul 2014 10:27:10 +0200 Organization: A noiseless patient Spider Message-ID: References: Reply-To: nonlegitur@futureapps.de Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Thu, 24 Jul 2014 08:27:11 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="4a8878deb6d5495afc708ca1c8a62e24"; logging-data="9126"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/cyhF6VB/BZlX1fE5J34uRcP2lYHILXJg=" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: Cancel-Lock: sha1:pXcpJjoLWIiMEVZ229XMr/VcaEI= Xref: number.nntp.dca.giganews.com comp.lang.ada:187824 Date: 2014-07-24T10:27:10+02:00 List-Id: On 24/07/14 00:12, Randy Brukardt wrote: > "G.B." wrote in message > news:lqoab0$bnm$1@dont-email.me... >> On 23.07.14 00:07, Randy Brukardt wrote: >>> with P, Q; use P, Q; >>> procedure R is >>> begin >>> if Error then -- (1) >>> raise Error; -- (2) >>> end if; >>> end R; >>> >>> both (1) and (2) are illegal today. But there's no good reason for that; >>> the >>> profiles (imagining an extended idea of profile to include objects and >>> exceptions) are different and there can be no more confusion between them >>> than between overloaded enumeration literals. >> >> Well, this text gives the reader a lucid hint at what the homonyms >> might mean! Sounds like more context dependency as we have some >> already, don't we. Good grief. > > I think you miss the point. This isn't something that one intentionally > writes (and "Error" is a terrible name just used for an example). But if one > intends to reuse code, the client has no control over the naming of the > entities in the reused code. Moreover (and more important), the client > shouldn't break due to unrelated maintenance on some third-party code. I disagree, because the client should perhaps be diagnosed broken, for reasons of maintainability of references. The latter word is meant in the generals sense: if it takes a name resolution program to know the named objects (again in the general sense of the word), then the program's project management could be steering in a direction of more helpful naming rather than in that of more complex compiler technology. That is, if it's broken, fix it. If it needs overloading, take care. Do not rely on ever more capable, ever more sophisticated overload resolution technology in this case. IOW, find it suspicious if your compiler vendor praises a somewhat complicated techno feature that makes your bundle of homonyms still work! ;-) ;-) ;-) > Especially if that third-party code decides to add something with the same > name as something that you are already using. How could they know to avoid > it? Neither can I. (Example below.) > One could imagine a rule "no use clauses of any kind, anywhere", but that's > not really practical (especially as it means no infix operator usage). In > the absence of that, you're going to be at risk for problems. Moreover, even > if "prefixes are good", they also make code unreadable (particularly if you > have lots of child packages). I agree that some kind of abbreviation mechanism is necessary. But not through overloading, if possible. I'd rather have more errors appearing (sic), since they can be fixed, rather than having them swept under the rug, which is what extensive overloading will do. (Hence the example of Javascript obfuscation; while technically correct, the result is not maintainable.) That's on the premiss, of course, that a reader of an ideal Ada program will know the object that some given name denotes without doing too much resolution himself. > Ada has many rules that are intended to prevent Beaujolais and Ripple > effects. Yes, and I'd like to adduce the rules that make an inner P hide an outer P, with no "use" in sight. The client might have to manipulate visibility of names in this case, too. package P is Q : array (Natural range 8 .. 15) of Boolean; end P; with P; -- added, "incompetent programmer" wonders about effect procedure Client is package P is -- suppose "competent reviewer" had skipped -- this nested inner P on first reading ... function Q (N : Natural) return Boolean; end P; package body P is separate; begin if P.Q (12) then -- ... and now both assume things. null; end if; end Client; Writing "with P;" on top of Client doesn't change this program a bit, provided that P's elaboration has no effects. But it does change all sorts of assumptions. Adding more overloading could not possibly remove the effects of more assumptions? The same argument applies to with-ing packages from two or more different libraries, I think. While it might seem tempting to have a "smart" compiler resolve all naming issues through some kind of "smart" overloading, I'm reluctant to call that a solution. It might help getting a particular job done, but since I'm constantly in a position of having to deal with the results in the long run, I cannot like it that much. > To avoid overloading ("homonyms"), > then you have to avoid "+" and Put and Read and Image and lots of other > things. I think that homonyms like "+" and "Put" could be put on the "overriding" side of "overriding vs overloading", couldn't they? (If we are allowed to think in terms of a suitably changed language, one that reinterprets Ada text without changing the effect of code generated for a + b.) >> This over-overloading, rightfully frowned upon by SPARK ... > > SPARK avoids overloading because the original authors of the tools didn't > have enough knowledge of how to implement it. (...) [I have turned this political argument---about what is not---around, in the paragraph about compiler writers who like to sell more overloading. 8-) ]