Ambiguity detected - Why?

Ambiguity detected - Why?

[Alan Paterson]

The following results when compiling using DECAda/VMS. We cannot understand why 
the compiler finds the marked call ambiguous. Can anyone explain it?

      1 procedure AMBIGUITY_TEST is
      2 --
      3    type T_ENUM is (A, B, C);
      4 --
      5    type T_ENUM_ARR is array(POSITIVE range <>) of T_ENUM;
      6 --
      7 -- 
-----------------------------------------------------------------------------
      8    procedure PROC(
      9                 PARA : in STRING) is
     10    begin
     11       null;
     12    end PROC;
     13 -- 
-----------------------------------------------------------------------------
     14    procedure PROC(
     15                 PARA : in T_ENUM_ARR) is
     16    begin
     17       null;
     18    end PROC;
     19 -- 
-----------------------------------------------------------------------------
     20 --
     21 begin
     22    PROC((A, B));
...............1
%ADAC-E-AMBIGRSL, (1) Ambiguity detected during overload resolution [LRM 8.7]
%ADAC-I-SUPPMEAN, (1) For procedure call PROC the meanings considered are
            call of procedure body PROC (STRING) declared at line 8
            call of procedure body PROC (T_ENUM_ARR) declared at line 14
        For array aggregate the result type is any non-limited array or record 
type

     23    PROC("(A, B)");
     24    PROC(T_ENUM_ARR'(A, B));
     25 end AMBIGUITY_TEST;


-- 
Alan Paterson
Berne, Switzerland

Re: Ambiguity detected - Why?

[Robert A Duff]

In article <31B590D2.4193@dial.eunet.ch>,
Alan Paterson  <paterson@dial.eunet.ch> wrote:
>The following results when compiling using DECAda/VMS. We cannot understand why 
>the compiler finds the marked call ambiguous. Can anyone explain it?

>     22    PROC((A, B));
>...............1
>%ADAC-E-AMBIGRSL, (1) Ambiguity detected during overload resolution [LRM 8.7]

The type of an aggregate must be determined by the surrounding context.
The compiler is not allowed to look inside the aggregate in order to
determine its type.  In Ada 95, this is 4.3(3).  There's an equivalent
rule in Ada 83, worded differently.  The compiler thinks, OK I've got an
aggregate, so it must be of some composite type, but I don't know which
composite type, since I'm not allowed to look inside the aggregate.  But
I've got two different things called PROC, which both take a parameter
of a composite type, so I've got an ambiguity.

No big deal -- just use a qualified expression to tell the compiler what
type you meant.

- Bob

Re: Ambiguity detected - Why?

[Adam Beneschan]

Alan Paterson <paterson@dial.eunet.ch> writes:
 >The following results when compiling using DECAda/VMS. We cannot understand why 
 >the compiler finds the marked call ambiguous. Can anyone explain it?
 >
 >      1 procedure AMBIGUITY_TEST is
 >      2 --
 >      3    type T_ENUM is (A, B, C);
 >      4 --
 >      5    type T_ENUM_ARR is array(POSITIVE range <>) of T_ENUM;
 >      6 --
 >      7 -- 
 >-----------------------------------------------------------------------------
 >      8    procedure PROC(
 >      9                 PARA : in STRING) is
 >     10    begin
 >     11       null;
 >     12    end PROC;
 >     13 -- 
 >-----------------------------------------------------------------------------
 >     14    procedure PROC(
 >     15                 PARA : in T_ENUM_ARR) is
 >     16    begin
 >     17       null;
 >     18    end PROC;
 >     19 -- 
 >-----------------------------------------------------------------------------
 >     20 --
 >     21 begin
 >     22    PROC((A, B));
 >...............1
 >%ADAC-E-AMBIGRSL, (1) Ambiguity detected during overload resolution [LRM 8.7]
 >%ADAC-I-SUPPMEAN, (1) For procedure call PROC the meanings considered are
 >            call of procedure body PROC (STRING) declared at line 8
 >            call of procedure body PROC (T_ENUM_ARR) declared at line 14
 >        For array aggregate the result type is any non-limited array or record 
 >type
 >
 >     23    PROC("(A, B)");
 >     24    PROC(T_ENUM_ARR'(A, B));
 >     25 end AMBIGUITY_TEST;

8.7(12) explains this: "The rules that require the type of an
aggregate or string literal to be determinable solely from the
enclosing complete context...".

This isn't an easy statement to understand.  But basically, it means
that when the compiler is trying to figure out which overloaded
subprogram is trying to use, if it sees that the parameter is an
aggregate, it doesn't have to look at the whole aggregate to figure
out what type it is.  All it has to do is say, "This is an aggregate."
So when it sees (A,B) in your example, it starts looking for a
declaration of PROC that takes any composite type (i.e. array or
record) as a parameter.  Since both of your declarations take array
types as parameters, the call to PROC is considered ambiguous.

I hope my explanation helps.  IMHO, this isn't one of the easier Ada
rules to understand.  If you really don't want to change the name of
one of your PROC's, the form you used on line 24 will work fine.

                                -- Adam