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-11 10:34:59 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!cambridge1-snf1.gtei.net!news.gtei.net!inmet!not-for-mail From: Tucker Taft Newsgroups: comp.lang.ada Subject: Re: Calling through function pointer--syntax question Date: Mon, 11 Jun 2001 13:34:59 -0400 Organization: AverStar (formerly Intermetrics) Burlington, MA USA Message-ID: <3B250143.CF413609@averstar.com> References: <9fj5nm$sg0$1@news.netmar.com> <3B1E539E.CF306AC6@averstar.com> <3B1ED74B.BFC95722@acm.org> NNTP-Posting-Host: nebula.burl.averstar.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------A84963B3C2389D8D98C75DB9" X-Trace: inmet2.burl.averstar.com 992280898 8885 141.199.8.77 (11 Jun 2001 17:34:58 GMT) X-Complaints-To: usenet@inmet2.burl.averstar.com NNTP-Posting-Date: 11 Jun 2001 17:34:58 GMT X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en Xref: archiver1.google.com comp.lang.ada:8561 Date: 2001-06-11T17:34:58+00:00 List-Id: This is a multi-part message in MIME format. --------------A84963B3C2389D8D98C75DB9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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) --------------A84963B3C2389D8D98C75DB9 Content-Type: text/plain; charset=us-ascii; name="test_ambig.ada.lst" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="test_ambig.ada.lst" 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 --------------A84963B3C2389D8D98C75DB9--