Calling through function pointer--syntax question

Calling through function pointer--syntax question

[adam]

Is the last procedure call in the program ambiguous?

If this is a legal program, what should it do?

                                -- thanks, Adam


with text_io;  use text_io;
procedure test is
    
    type func_ptr is access function (param : integer) return integer;
    
    procedure P (x : in integer);
    procedure P (x : in func_ptr);
    function func1 (param : integer) return integer;
    
    function func (y : integer := 4) return func_ptr is
    begin
        text_io.put_line ("func parameter is " & integer'image (y));
        return func1'access;
    end func;

    procedure P (x : in integer) is
    begin
        text_io.put_line ("P with integer parameter called: " &
                          integer'image (x));
    end P;

    procedure P (x : in func_ptr) is
    begin
        text_io.put_line ("P with function parameter called");
    end P;

    function func1 (param : integer) return integer is
    begin
        text_io.put_line ("func1 parameter is " & integer'image (param));
        return param * 2;
    end func1;

begin
    P (func (5));       -- IS THIS AMBIGUOUS?
end test;

 -----  Posted via NewsOne.Net: Free (anonymous) Usenet News via the Web  -----
  http://newsone.net/ -- Free reading and anonymous posting to 60,000+ groups
   NewsOne.Net prohibits users from posting spam.  If this or other posts
made through NewsOne.Net violate posting guidelines, email abuse@newsone.net

Re: Calling through function pointer--syntax question

[tmoran]

>   P (func (5));       -- IS THIS AMBIGUOUS?
 It looks quite clear to me.  func(5) should print
func parameter is  5
and return a func_ptr, namely func1'access. Then P(func_ptr) should print
P with function parameter called
Indeed, when I compile and execute that's what I get.  Why did you worry?

Re: Calling through function pointer--syntax question

[Tucker Taft]

adam@irvine.com wrote:
> 
> Is the last procedure call in the program ambiguous?

No.  Even if func_ptr had a default expression for
its "param" it would still be unambiguous, because
you need an explicit ".all" to call through a function
pointer when there are no explicit parameters passed.
An implicit ".all" is provided prior to "(" and ".<component>"
but not in other places.
 
> 
> If this is a legal program, what should it do?

This calls the "P" that takes a func_ptr.

> 
>                                 -- thanks, Adam
> 
> ...
-- 
-Tucker Taft   stt@avercom.net   http://www.avercom.net
Chief Technology Officer, AverCom Corporation (A Titan Company) 
Burlington, MA  USA (AverCom was formerly the Commercial Division of AverStar:
http://www.averstar.com/~stt)

Re: Calling through function pointer--syntax question

[Adam Beneschan]

tmoran@acm.org (Tom Moran) wrote in message 
news:<UzaT6.65786$%i7.49756743@news1.rdc1.sfba.home.com>...

> >   P (func (5));       -- IS THIS AMBIGUOUS?
>  It looks quite clear to me.  func(5) should print
> func parameter is  5
> and return a func_ptr, namely func1'access. Then P(func_ptr) should print
> P with function parameter called
> Indeed, when I compile and execute that's what I get.  Why did you worry?

Because there's another possible interpretation of the last call: 
"func" is called with the default parameter, 4, and returns a func_ptr; the
function designated by func_ptr is called with one parameter, 5 [no .all is 
necessary on the function access since there is a parameter list], and 
returns an integer (10); and then the P that takes an integer parameter is 
called with the parameter 10.

I wanted to find out whether this was ambiguous because there are two legal
interpretations, or whether there's a language rule I'm missing that makes one
of the two interpretations impossible, or gives precedence to one over the
other.

				-- thanks, Adam

Re: Calling through function pointer--syntax question

[Adam Beneschan]

Tucker Taft <stt@averstar.com> wrote in message news:<3B1E539E.CF306AC6@averstar.com>...
> adam@irvine.com wrote:
> > 
> > Is the last procedure call in the program ambiguous?
> 
> No.  Even if func_ptr had a default expression for
> its "param" it would still be unambiguous, because
> you need an explicit ".all" to call through a function
> pointer when there are no explicit parameters passed.
> An implicit ".all" is provided prior to "(" and ".<component>"
> but not in other places.

Sorry, I'm not following . . . the default parameter in my example is on the
function "func", not on the function *pointer*.  In the call
    P (func (5));
since an implicit .all is provided prior to "(", why couldn't this be
interpreted as
    P (func.all (5));
[here it's clear that the default parameter is passed to "func"]?

				-- Adam

Re: Calling through function pointer--syntax question

[Jeffrey Carter]

Adam Beneschan wrote:
> 
> Sorry, I'm not following . . . the default parameter in my example is on the
> function "func", not on the function *pointer*.  In the call
>     P (func (5));
> since an implicit .all is provided prior to "(", why couldn't this be
> interpreted as
>     P (func.all (5));
> [here it's clear that the default parameter is passed to "func"]?

The implicit ".all" also means the "(" starts the parameter list of the
function being pointed to. You never get an implicit ".all" if there are
no explicit parameters.

-- 
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python & the Holy Grail

Re: Calling through function pointer--syntax question

[Adam Beneschan]

Jeffrey Carter <jrcarter@acm.org> wrote in message news:<3B1ED74B.BFC95722@acm.org>...
> Adam Beneschan wrote:
> > 
> > Sorry, I'm not following . . . the default parameter in my example is on the
> > function "func", not on the function *pointer*.  In the call
> >     P (func (5));
> > since an implicit .all is provided prior to "(", why couldn't this be
> > interpreted as
> >     P (func.all (5));
> > [here it's clear that the default parameter is passed to "func"]?
> 
> The implicit ".all" also means the "(" starts the parameter list of the
> function being pointed to. You never get an implicit ".all" if there are
> no explicit parameters.


At the risk of being taunted a second time, and possibly even having a
cow hurled down on top of me (or perhaps some other unit of
livestock), I feel that I need to respond again.  I know that it looks
really bad to ask a question and then argue with everyone who's kind
enough to answer.  However, the responses I've gotten have been
confusing, and I don't know whether it's me or everyone else who's
confused.  If it's me, I hope someone will be kind enough to point out
exactly where I got confused.

Anyway, it seems to me that the procedure call in question *is*
ambiguous, contrary to what everyone else (including someone's
compiler) says, and I'll try to explain in more precise detail why I
think so:

The relevant declarations are:

    type func_ptr is access function (param : integer) return integer;
    function func (y : integer := 4) return func_ptr;
    procedure P (x : in integer);
    procedure P (x : in func_ptr);

and my question is about the procedure call:

    P (func (5));       

Obviously, one acceptable interpretation is that "func" is called with
the parameter 5, returning a func_ptr, and this func_ptr is passed to
the second P.

I believe the other interpretation is also acceptable, however: "func"
is called with a default parameter, 4.  This returns a function
pointer.  This function pointer is dereferenced, and the designated
function is called with the parameter 5.  This returns an integer, and
the resulting integer is passed to the first P.

I don't see any reason why this would be unacceptable.  6.4(8) says
that when there is an actual_parameter_part, the "prefix" of the
function call can be an implicit_dereference of an
access-to-subprogram value.  In the construct func(5), there is an
actual parameter part, (5), and therefore, the prefix, "func", may be
an implicit_dereference.  An implicit_dereference is just a "name",
and a function call is one sort of name; and I see nowhere in 4.1 that
puts any restrictions on what kind of "name" is acceptable for an
implicit_dereference (in particular, there are no restrictions on the
name being a call to a parameterless function or a function call with
no actual parameter part).  Thus, since "func" (all by itself, with no
parameters) is a legal function call (note that there is no implicit
dereference involved at all in *this* function call), and since
there's nothing disallowing this function call from being an
implicit_dereference, it appears to me that treating "func" as an
implicit_dereference (within the construct func(5)) is an acceptable
interpretation.

To summarize, there are two function calls going on in the same
expression: func and func(5).  The first one doesn't have explicit
parameters, but that's OK since it doesn't call through a pointer.
The second, func(5), does have explicit parameters, and it's therefore
legal for it to contain an implicit dereference.

Since there are two acceptable interpretations, the call is therefore
ambiguous by 8.6(30).

I haven't understood the responses I've gotten.  Both of them said, in
effect, that you need an explicit .all to call through a function
pointer when there are no explicit parameters---but in the second
acceptable interpretation, there *is* an explicit parameter (5).

Does this make it clearer to everyone?  Or does it make it clearer to
everyone that I belong in the looney bin?  Is there an error in my
line of thought?  

                                -- thanks, Adam

Re: Calling through function pointer--syntax question

[Simon Wright]

adam@irvine.com (Adam Beneschan) writes:

>     type func_ptr is access function (param : integer) return integer;
>     function func (y : integer := 4) return func_ptr;
>     procedure P (x : in integer);
>     procedure P (x : in func_ptr);
> 
> and my question is about the procedure call:
> 
>     P (func (5));       

This has to be the second P. If you were meaning to call the first P,
you would write

    P (func.all (5));

  with Ada.Text_Io; use Ada.Text_Io;
  Procedure Q is
    type Func_Ptr is access function (Param : Integer) return Integer;
    function Actual (Param : Integer) return Integer is
    begin
      return 0;
    end Actual;
    function Func (Y : Integer := 4) return Func_Ptr is
    begin
      return Actual'Access;
    end Func;
    procedure P (X : in Integer) is
    begin
      Put_Line ("first interpretation");
    end P;
    procedure P (X : in Func_Ptr) is
   begin
      Put_Line ("second interpretation");
    end P;
  begin
    P (Func (5));
    P (Func.all (5));
  end Q;

results in

  second interpretation
  first interpretation

(GNAT 3.14a)

Re: Calling through function pointer--syntax question

[Philip Anderson]

Simon Wright wrote:
> 
> This has to be the second P. If you were meaning to call the first P,
> you would write

Would or must?
 
>     P (func.all (5));
> 
>   with Ada.Text_Io; use Ada.Text_Io;
>   Procedure Q is
>     type Func_Ptr is access function (Param : Integer) return Integer;
>     function Actual (Param : Integer) return Integer is
>     begin
>       return 0;
>     end Actual;
>     function Func (Y : Integer := 4) return Func_Ptr is
>     begin
>       return Actual'Access;
>     end Func;
>     procedure P (X : in Integer) is
>     begin
>       Put_Line ("first interpretation");
>     end P;
>     procedure P (X : in Func_Ptr) is
>    begin
>       Put_Line ("second interpretation");
>     end P;
>   begin
>     P (Func (5));
>     P (Func.all (5));
>   end Q;
> 
> results in
> 
>   second interpretation
>   first interpretation
> 
> (GNAT 3.14a)

Using Rational Apex for NT 3.0.2b, this gives an error:

*** Unit has semantic errors
P could be (in Q) P
P could be (in Q) P
P (Func (5)); is an ambiguous call

Commenting out the second P, it compiles quite happily, resulting in

first interpretation
first interpretation


Likewise, using named parameter association to disambiguate calls

P (Func (Param => 5));
P (Func (Y => 5));
P (Func.all (5));

which is accepted, and results in

first interpretation
second interpretation
first interpretation


So I think Adam does have a case.  Also, either Rational or Gnat appears
to have a bug.


-- 
hwyl/cheers,
Philip Anderson
Alenia Marconi Systems
Cwmbr�n, Cymru/Wales

Re: Calling through function pointer--syntax question

[Tucker Taft]

[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]

Adam Beneschan wrote:
> ...
> At the risk of being taunted a second time, and possibly even having a
> cow hurled down on top of me (or perhaps some other unit of
> livestock), I feel that I need to respond again. 

Despite my earlier response, I now agree with you.
I hadn't looked at your example closely enough the
first time.


> ...
> Anyway, it seems to me that the procedure call in question *is*
> ambiguous, contrary to what everyone else (including someone's
> compiler) says, and I'll try to explain in more precise detail why I
> think so:
> 
> The relevant declarations are:
> 
>     type func_ptr is access function (param : integer) return integer;
>     function func (y : integer := 4) return func_ptr;
>     procedure P (x : in integer);
>     procedure P (x : in func_ptr);
> 
> and my question is about the procedure call:
> 
>     P (func (5));
> 
> Obviously, one acceptable interpretation is that "func" is called with
> the parameter 5, returning a func_ptr, and this func_ptr is passed to
> the second P.
> 
> I believe the other interpretation is also acceptable, however: "func"
> is called with a default parameter, 4.  This returns a function
> pointer.  This function pointer is dereferenced, and the designated
> function is called with the parameter 5.  This returns an integer, and
> the resulting integer is passed to the first P.

Yes, I agree with your analysis.

> ... Is there an error in my
> line of thought?

No.
(And my favorite Ada front end agrees with you too -- I should
have checked with it first!)

[I have attached a listing.]

> 
>                                 -- thanks, Adam

-- 
-Tucker Taft   stt@avercom.net   http://www.avercom.net
Chief Technology Officer, AverCom Corporation (A Titan Company) 
Burlington, MA  USA (AverCom was formerly the Commercial Division of AverStar:
http://www.averstar.com/~stt)

[-- Attachment #2: test_ambig.ada.lst --]
[-- Type: text/plain, Size: 670 bytes --]

Source file: test_ambig.ada   Mon Jun 11 13:30:34 2001

    1 procedure test_ambig is
    2     type func_ptr is access function (param : integer) return integer;
    3     function func (y : integer := 4) return func_ptr is begin return null; end;
    4     procedure P (x : in integer) is begin null; end;
    5     procedure P (x : in func_ptr) is begin null; end;
    6 
    7 -- and my question is about the procedure call:
    8 
    9 begin
   10 
   11     P (func (5));       
          *
*****Error: LRM:8.6(31) Ambiguous call, possible definitions of P appear at
*****        line 5 of file test_ambig.ada, line 4 (same file).
   12 
   13 end;
   14 
   15