* Question about name resolution @ 2015-01-20 18:47 Michael B. 2015-01-20 19:00 ` Jeffrey Carter 2015-01-20 19:43 ` Robert A Duff 0 siblings, 2 replies; 8+ messages in thread From: Michael B. @ 2015-01-20 18:47 UTC (permalink / raw) The following example does not compile because the call to "P" is ambiguous: procedure Main is procedure P is begin null; end P; procedure P (I : Integer := 0) is begin null; end P; begin P; end Main; What syntax is needed to call the first "P" without parameters? Regards, Michael ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Question about name resolution 2015-01-20 18:47 Question about name resolution Michael B. @ 2015-01-20 19:00 ` Jeffrey Carter 2015-01-20 19:32 ` Michael B. 2015-01-20 19:43 ` Robert A Duff 1 sibling, 1 reply; 8+ messages in thread From: Jeffrey Carter @ 2015-01-20 19:00 UTC (permalink / raw) On 01/20/2015 11:47 AM, Michael B. wrote: > The following example does not compile because the call to "P" is ambiguous: > > procedure Main is > > procedure P is > begin > null; > end P; > > procedure P (I : Integer := 0) is > begin > null; > end P; > > begin > P; > end Main; > > What syntax is needed to call the first "P" without parameters? There's no way to call the 1st P by the name P. You could rename it and call it by the renamed name. -- Jeff Carter "Ada has made you lazy and careless. You can write programs in C that are just as safe by the simple application of super-human diligence." E. Robert Tisdale 72 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Question about name resolution 2015-01-20 19:00 ` Jeffrey Carter @ 2015-01-20 19:32 ` Michael B. 2015-01-20 20:39 ` Robert A Duff 2015-01-21 0:47 ` Jeffrey Carter 0 siblings, 2 replies; 8+ messages in thread From: Michael B. @ 2015-01-20 19:32 UTC (permalink / raw) On 01/20/15 20:00, Jeffrey Carter wrote: > There's no way to call the 1st P by the name P. You could rename it and call it > by the renamed name. It works, thank you! I found something similar in a library that I want to use. I was surprised that this compiles without warnings if neither of the procedures is called. Why is such overloading allowed in Ada? It seems to make no sense to write a procedure that cannot be called directly. Regards, Michael ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Question about name resolution 2015-01-20 19:32 ` Michael B. @ 2015-01-20 20:39 ` Robert A Duff 2015-01-21 18:25 ` Michael B. 2015-01-21 0:47 ` Jeffrey Carter 1 sibling, 1 reply; 8+ messages in thread From: Robert A Duff @ 2015-01-20 20:39 UTC (permalink / raw) "Michael B." <michaelb@example.com> writes: > On 01/20/15 20:00, Jeffrey Carter wrote: >> There's no way to call the 1st P by the name P. You could rename it and call it >> by the renamed name. > > It works, thank you! > I found something similar in a library that I want to use. > I was surprised that this compiles without warnings if neither of the > procedures is called. Why is such overloading allowed in Ada? It seems > to make no sense to write a procedure that cannot be called directly. There is an attempt to forbid overloaded declarations that can never be called because of ambiguity. See RM-8.3(26). It's quite complicated, and it doesn't really work -- it has both false positives and false negatives. Your case is a false negative. This rule is followed in the Annotated version by 25 paragraphs of explanatory text! See AARM-8.3(26.a-26.k). And several AI's were needed to fix bugs in this rule. I challenge you to provide wording that would forbid your case, and cases like it. ;-) A modification or addition to 8.3(26), I mean. It's not easy! I think the rule is a waste of time. If you have ambiguous calls, you'll find out at compile time even without that rule, albeit maybe in some other compilation unit. Not a big deal. Here's an example of a false positive: package P is type A is array (Positive range <>) of Integer; function Count(From, Up_To: Integer) return A; -- Returns an array from From up to Up_To, so -- Count(From => 1, Up_To => 4) returns (1, 2, 3, 4). function Count(From, Down_To: Integer) return A; -- Illegal homograph! -- E.g. Count(From => 4, Down_To => 1) returns (4, 3, 2, 1). end P; That's illegal, but if it were legal, you could write nonambiguous calls using named notation. - Bob ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Question about name resolution 2015-01-20 20:39 ` Robert A Duff @ 2015-01-21 18:25 ` Michael B. 0 siblings, 0 replies; 8+ messages in thread From: Michael B. @ 2015-01-21 18:25 UTC (permalink / raw) On 01/20/15 21:39, Robert A Duff wrote: > This rule is followed in the Annotated version by 25 paragraphs of > explanatory text! See AARM-8.3(26.a-26.k). And several AI's were > needed to fix bugs in this rule. > > I challenge you to provide wording that would forbid your case, > and cases like it. ;-) A modification or addition to 8.3(26), > I mean. It's not easy! I give up ;-) Since I never came across this problem before, the current rules seem to be quite okay... And thank you for the explanation. Regards, Michael ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Question about name resolution 2015-01-20 19:32 ` Michael B. 2015-01-20 20:39 ` Robert A Duff @ 2015-01-21 0:47 ` Jeffrey Carter 2015-01-21 10:54 ` Brian Drummond 1 sibling, 1 reply; 8+ messages in thread From: Jeffrey Carter @ 2015-01-21 0:47 UTC (permalink / raw) On 01/20/2015 12:32 PM, Michael B. wrote: > > I was surprised that this compiles without warnings if neither of the procedures > is called. Why is such overloading allowed in Ada? It seems to make no sense to > write a procedure that cannot be called directly. Duff has discussed the current state of Ada regarding this. In Ada 80, subprograms without parameters had to be called with an empty parameter list. This was universally reviled and so it was removed in Ada 83. I don't remember enough about this to say how it would have applied in your case. The illustration of the difference I remember was function F (I : Integer) return Integer; -- F1 type IA is array (Integer range <>) of Integer; function F return IA; -- F2 In Ada 83 and later, the call F (5) is ambiguous. It could either be F1 with an argument of 5 or F2 with the result indexed by 5 In Ada 80 this was unambiguous; the call could only be to F1. To call F2 one had to write F () (5) This is not very helpful but I always like an excuse to air the useless trivia in my head. -- Jeff Carter "Ada has made you lazy and careless. You can write programs in C that are just as safe by the simple application of super-human diligence." E. Robert Tisdale 72 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Question about name resolution 2015-01-21 0:47 ` Jeffrey Carter @ 2015-01-21 10:54 ` Brian Drummond 0 siblings, 0 replies; 8+ messages in thread From: Brian Drummond @ 2015-01-21 10:54 UTC (permalink / raw) On Tue, 20 Jan 2015 17:47:20 -0700, Jeffrey Carter wrote: > On 01/20/2015 12:32 PM, Michael B. wrote: >> >> I was surprised that this compiles without warnings if neither of the >> procedures is called. Why is such overloading allowed in Ada? It seems >> to make no sense to write a procedure that cannot be called directly. > In Ada 83 and later, the call > > F (5) > > is ambiguous. It could either be > > F1 with an argument of 5 > > or > > F2 with the result indexed by 5 > > In Ada 80 this was unambiguous; the call could only be to F1. To call F2 > one had to write > > F () (5) > > This is not very helpful but I always like an excuse to air the useless > trivia in my head. Similar ambiguity was inherited by VHDL. Some big-name simulators still get it wrong, arbitrarily resolving the ambiguity as F1 with argument, some failing to compile legal VHDL where the ambiguity could be resolved by the return type. For example where F returns a string of specified (or default) length: function F(Len : Natural := 5) return String; variable c: character := F(5); is legal, unambiguous, yet rejected by some embarrassingly expensive tools, where variable s : string := "hello " & F(5); is ambiguous (because "&") overloads) but arbitrarily resolved as concatenating two strings. -- Brian -- Brian ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Question about name resolution 2015-01-20 18:47 Question about name resolution Michael B. 2015-01-20 19:00 ` Jeffrey Carter @ 2015-01-20 19:43 ` Robert A Duff 1 sibling, 0 replies; 8+ messages in thread From: Robert A Duff @ 2015-01-20 19:43 UTC (permalink / raw) "Michael B." <michaelb@example.com> writes: > The following example does not compile because the call to "P" is ambiguous: > > procedure Main is > > procedure P is > begin > null; > end P; > > procedure P (I : Integer := 0) is > begin > null; > end P; > > begin > P; > end Main; > > What syntax is needed to call the first "P" without parameters? The correct syntax is as follows: procedure Main is procedure Some_Other_Name is begin null; end Some_Other_Name; procedure P (I : Integer := 0) is begin null; end P; begin P; end Main; There are three ways to resolve overloading ambiguities: 1. Change the names (use less overloading). 2. Use qualified expressions (e.g. String'(F(X))). 3. Use expanded names (e.g. Package_Name.Procedure_Name). Only 1 works here. If the things are declared in third-party libraries that you can't change (or don't want to), then only 2 and 3 work. Otherwise, if you're getting a lot of ambiguities, 1 is often (usually?) the right way. - Bob ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2015-01-21 18:25 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-01-20 18:47 Question about name resolution Michael B. 2015-01-20 19:00 ` Jeffrey Carter 2015-01-20 19:32 ` Michael B. 2015-01-20 20:39 ` Robert A Duff 2015-01-21 18:25 ` Michael B. 2015-01-21 0:47 ` Jeffrey Carter 2015-01-21 10:54 ` Brian Drummond 2015-01-20 19:43 ` Robert A Duff
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox