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: Tue, 22 Jul 2014 17:07:55 -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 1406066875 19491 69.95.181.76 (22 Jul 2014 22:07:55 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 22 Jul 2014 22:07:55 +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:21149 Date: 2014-07-22T17:07:55-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:cso9nzjs6q5q$.16o96j9yv70q1$.dlg@40tude.net... > On Mon, 21 Jul 2014 18:23:05 -0500, Randy Brukardt wrote: > >> Otherwise, I think all objects (including exceptions) should allow >> overloading. > > What would be of exception renaming then? Would it create a new, possibly, > overloaded with itself object? That would be fun! ??? I don't see a problem. Resolution works as it does now for subprograms, and either there is a unique resolution or not. No one says "what would be of function renaming if overloading is allowed" -- it just is and everything is fine. The primary reason for allowing overloading of exceptions (as with objects) is so that they don't get hidden by something unrelated. (Especially a problem for use clauses.) If you have something like (assume these declarations have real names and the packages contain dozens of declarations each): package P is Error : Boolean; end P; package Q is Error : exception; end Q; 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. If you've got entities with the same names and profiles in different packages, that's a problem that should be detected. But so long as the profiles are different (and that's almost always the case), then there shouldn't be a problem (which is not the case today). A thought just popped into my head, perhaps you are worrying about: Name_Error : exception renames IO_Exceptions.Name_Error; This is thought by many to be a long time bug in Ada. If you have "use Text_IO, IO_Exceptions;" then "raise Name_Error;" is illegal -- but that's silly because both possibilities are the same entity. That could be fixed by adopting a rule such that if the only reason that a name is ambiguious is because it resolved to several different views of the same entity, that it would be treated as properly resolved to the entity. The only thing the compiler (or reader, for that matter) need care about is underlying entity, not exactly which view is involved. That would be additional complication in the language rules, but an Ada programmer would almost never care about it. In any case, this isn't necessary to support object and exception overloading; it would help some, but more importantly it's probably a good idea on its own. Randy.