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!gegeweb.org!news.ecp.fr!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Functions vs constants Date: Wed, 23 Jul 2014 17:12:21 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1406153545 13317 69.95.181.76 (23 Jul 2014 22:12:25 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 23 Jul 2014 22:12:25 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:21168 Date: 2014-07-23T17:12:21-05:00 List-Id: "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. 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? We had massive amounts of this problem with Claw. Almost anything one could do to the library would break break some possible use of the library. The less this is the case, the better, because it's surely not possible to encase libraries in amber (never changing them). And people using outdated versions of things is a severe problem for a software developer; it makes support difficult to impossible. 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). Ada has many rules that are intended to prevent Beaujolais and Ripple effects (cases where adding or deleting an unrelated declaration changes a legal program into a legal program with a different meaning). The best of these rules is overloading, because it doesn't make previously legal programs illegal because of some unrelated change. All of the other rules are a maintenance hazard, because they make legal programs illegal just because someone added something you don't care about. Finally, a lot of what you say boils down to "overloading is bad". In that case, you shouldn't be using Ada at all, since it heavily depends on overloading (all the way back to Ada 83). To avoid overloading ("homonyms"), then you have to avoid "+" and Put and Read and Image and lots of other things. It would only be practical to avoid overloading if all of your Ada code was constructed by your team, with no outside code ever involved. Then you could control the names used in the code. But that's not practical for any but the smallest projects. > 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. They then explained that as a "benefit", but the only benefit is that it simplified their tools. SPARK is a terrible example to use for programming language design, because the primary design criteria was what they knew how to implement. They left out a lot of stuff that is perfectly safe for their purposes, which really emasculates the language for no good reason at all. (They claim to have reasons, but those appear to be to have been constructed after the fact. It's easy to do, we did it a lot during the early subset days of Janus/Ada -- it's easy to spin nearly any limitation as a feature.) Randy.