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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a00006d3c4735d70 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-02-29 06:10:28 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!crtntx1-snh1.gtei.net!news.gtei.net!newsfeed1.easynews.com!newsfeed3.easynews.com!easynews.com!easynews!border1.nntp.sjc.giganews.com!nntp.giganews.com!local1.nntp.sjc.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Sun, 29 Feb 2004 08:10:27 -0600 Date: Sun, 29 Feb 2004 09:10:26 -0500 From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: In-Out Parameters for functions References: <4020C947.81A6D703@0.0> <1075907239.138068@master.nyc.kbcfp.com> <402232E9.3EE15B4B@0.0> <1075987360.225622@master.nyc.kbcfp.com> <40236C0B.E988E003@0.0> <1077634311.254581@master.nyc.kbcfp.com> <1077718871.47635@master.nyc.kbcfp.com> <54cp3095jmv8s17h63d4bjdus0tec7l7pt@jellix.jlfencey.com> <1077721343.481619@master.nyc.kbcfp.com> <1077727853.904323@master.nyc.kbcfp.com> <1077810250.28474@master.nyc.kbcfp.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 24.147.77.160 X-Trace: sv3-2JczDz8fmhQszU21ENfbRM0/H4mxgATAnaxp7zBxR7JuBwsXp8TfR5qvR3snEOEeNckcIYV+jiOZrUw!eflgzvEt0g4M+qd0RQOsmRUSGSVb0xcoiKOfes3SdnzHHvmblHmzOEGfgMFYpw== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Xref: archiver1.google.com comp.lang.ada:5947 Date: 2004-02-29T09:10:26-05:00 List-Id: Hyman Rosen wrote: > The section to which you refer defines a pair of "+" operations. > I don't see how they cause any issues for l-to-r. And pragma Inline > does not affect the semantics of a program, so again I don't see what > the relevance is. I do agree that there seem to be unholy complexities > lurking in the trade-offs between checking requirements and allowing > optimization which could be exacerbated by requiring l-to-r. You are getting there. Bob Mathis once told me a Lisp joke: (defun twiddle-thumbs thumb1 thumb2 (twiddle-thumbs thumb2 thumb1)) That really sums up the issue I was bringing up. The second function in that particular pair of functions is probably defined by: function "+"(Left : Storage_Offset; Right : Address) return Address is begin return Right + Left; end "+"; -- with pragma Inline in the spec. Now, when do you apply your left-to-right requirement, before or after the pragma Inline has been applied? Since the pragma Inline probably applies to both calls, I guess the answer has to be before the inlining. Thinking some more about your proposal, now that I have looked at it from all sides, a much more modest version seems reasonable: If an expression contains two non-pure, non-predefined functions they must be evaluated in canonical order instead of "some order." This would allow compilers to do all their code motion in most cases, and only expressions with two or more impure function calls would need to switch off some of those optimizations. You could probably modify GNAT to check the effects of that rule change out if you wanted to. (Or ask your compiler vendor to put in a switch--the result of turning on the switch would still be a legal implementation of Ada. Not that there is a requirement that compiler switches work that way.) Personally, as I said, I have written code that has to handle Constraint_Error in some cases, and reraise it in others. In those cases, for Ada 95, I not only have to break some expressions into two parts, but insure that the parts are covered by different exception handlers--in different packages. It is a pain to get that code right according to the (current) Ada 95/2000 rules, but I don't think your change would help. It is the permission in the last sentence of 11.6(6) that is the real issue. -- Robert I. Eachus "The only thing necessary for the triumph of evil is for good men to do nothing." --Edmund Burke