Re: Calling through function pointer--syntax question

[adam@irvine.com (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