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=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII
Path: 
 g2news2.google.com!postnews.google.com!d4g2000prc.googlegroups.com!not-for-mail
From: Adam Beneschan <adam@irvine.com>
Newsgroups: comp.lang.ada
Subject: Re: Dispatch on the result still does not work?
Date: Mon, 13 Jul 2009 08:13:41 -0700 (PDT)
Organization: http://groups.google.com
Message-ID: <9f845311-63a4-4d89-ac78-b6567b999417@d4g2000prc.googlegroups.com>
References: <ubjkmle9n5pi.1ovhyam5f9lf5$.dlg@40tude.net>
NNTP-Posting-Host: 66.126.103.122
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Trace: posting.google.com 1247498021 18437 127.0.0.1 (13 Jul 2009 15:13:41
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Mon, 13 Jul 2009 15:13:41 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: d4g2000prc.googlegroups.com; posting-host=66.126.103.122;
	posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64;
	SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR
	3.5.30729; .NET CLR 3.0.30618),gzip(gfe),gzip(gfe)
Xref: g2news2.google.com comp.lang.ada:7027
Date: 2009-07-13T08:13:41-07:00
List-Id: <comp.lang.ada>

On Jul 11, 3:04=A0am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> Considering this one:
>
> package P is
> =A0 =A0type T is tagged null record;
> =A0 =A0function Value return T;
>
> =A0 =A0type S is new T with null record;
> =A0 =A0function Value return S;
> end P;
>
> package body P is
> =A0 =A0function Value return T is
> =A0 =A0begin
> =A0 =A0 =A0 return (null record);
> =A0 =A0end Value;
>
> =A0 =A0function Value return S is
> =A0 =A0begin
> =A0 =A0 =A0 return (T with null record);
> =A0 =A0end Value;
> end P;
>
> use P;
>
> =A0 =A0X : T'Class :=3D S'(Value);
> begin
> =A0 =A0X :=3D Value; -- Ambiguous?
>
> I would expect it rather dispatching on the tag of X, i.e. selecting Valu=
e,
> which returns S.

The problem here (I mean the problem with your program, not a problem
with the Ada language) is that the overloading rules, which determine
what the meaning of the identifier "Value" is when there is more than
one possibility, do not take the dynamic semantics into account.  The
overloading rules basically work like this: We consider all possible
combinations of all possible meanings of the identifiers, then keep
only the legal ones (legal according to the "legality rules"; a
construct can still be legal even if it will always raise an exception
at runtime).  If there is more than one legal possibility, the
construct is ambiguous.  (This oversimplifies things a bit; there are
some exceptions regarding abstract subprograms.)

Or, to put it another way: The compiler *first* has to determine what
each of the identifiers in the statement means.  Only after this is
determined, *then* can it apply the dynamic-semantics rules about
dispatching.

Suppose the Value that returns T does not exist:

  package P is
     type T is tagged null record;
  -- function Value return T;

     type S is new T with null record;
     function Value return S;
  end P;
  ...

  use P;

     X : T'Class :=3D S'(Value);
  begin
     X :=3D Value;

The question here is, is the assignment statement legal?  And the
answer is "Yes", because the expected type (the type of X) is T'Class,
and the type of Value is S, which is a type in that class (8.6(21)).
Since this is legal, then if we uncomment the first Value, there would
be two legal interpretations for the statement "X :=3D Value", which
makes it ambiguous.

I believe this will work, although I'm not 100% certain; it is legal
and will dispatch, although the syntax could possibly make it look
like it won't dispatch:

     X : T'Class :=3D S'(Value);
  begin
     X :=3D T'(Value);

Making the call to Value a "qualified expression" tells the compiler
what the expected type of Value will be, and thus helps it determine
unambiguously which Value is meant.  If I have this straight, using a
qualified expression doesn't change the fact that the expression
("Value") is tag-indeterminate; and thus the assignment is still legal
by 5.2(6), and the call still dispatches by 3.9.2(18.1).

I think this also works:

     X : T'Class :=3D S'(Value);
  begin
     declare
        function T_Value return T renames Pak1.Value;
     begin
        X :=3D T_Value;
     end;

Again, the rename helps the compiler determine unambiguously which
Value subprogram is intended, but it doesn't change the fact that the
call to it is tag-indeterminate.  I'd need to pore over the rules more
closely to make sure of this, however.

Anyway, the important thing to remember is that the compiler first has
to determine which declaration is meant by every identifier in a
statement, and only *then* can it think about whether a call is
dispatching or not.

Hope this helps,

                                       -- Adam