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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,56ea95ca210cf316
X-Google-Attributes: gid103376,public
From: adam@irvine.com (Adam Beneschan)
Subject: Re: Ambiguity detected - Why?
Date: 1996/06/06
Message-ID: <4p77kd$qr8@krusty.irvine.com>#1/1
X-Deja-AN: 158821509
references: <31B590D2.4193@dial.eunet.ch>
organization: /z/news/newsctl/organization
newsgroups: comp.lang.ada
Date: 1996-06-06T00:00:00+00:00
List-Id: <comp.lang.ada>


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