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-7-bit X-Google-Thread: 103376,68e7fcc642995ece X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-06-08 14:34:18 PST Path: archiver1.google.com!newsfeed.google.com!postnews1.google.com!not-for-mail From: adam@irvine.com (Adam Beneschan) Newsgroups: comp.lang.ada Subject: Re: Calling through function pointer--syntax question Date: 8 Jun 2001 14:34:17 -0700 Organization: http://groups.google.com/ Message-ID: References: <9fj5nm$sg0$1@news.netmar.com> <3B1E539E.CF306AC6@averstar.com> <3B1ED74B.BFC95722@acm.org> NNTP-Posting-Host: 63.206.153.98 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 992036058 27858 127.0.0.1 (8 Jun 2001 21:34:18 GMT) X-Complaints-To: groups-support@google.com NNTP-Posting-Date: 8 Jun 2001 21:34:18 GMT Xref: archiver1.google.com comp.lang.ada:8455 Date: 2001-06-08T21:34:18+00:00 List-Id: Jeffrey Carter 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