Question about name resolution

Question about name resolution

[Michael B.]

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

Re: Question about name resolution

[Jeffrey Carter]

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

Re: Question about name resolution

[Michael B.]

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

Re: Question about name resolution

[Robert A Duff]

"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

Re: Question about name resolution

[Michael B.]

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

Re: Question about name resolution

[Jeffrey Carter]

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

Re: Question about name resolution

[Brian Drummond]

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

Re: Question about name resolution

[Robert A Duff]

"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