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,a00006d3c4735d70 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-02-29 07:15:44 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!zeus.visi.com!priapus.visi.com!orange.octanews.net!news-out.visi.com!petbe.visi.com!news.octanews.net!newshosting.com!nx01.iad01.newshosting.com!newsfeed.icl.net!newsfeed.fjserv.net!news-FFM2.ecrc.net!rcn!feed3.news.rcn.net!not-for-mail Sender: jsa@rigel.goldenthreadtech.com 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> From: j-anthony@rcn.com (Jon S. Anthony) Date: 29 Feb 2004 10:37:02 -0500 Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: DXC=: "Robert I. Eachus" writes: > 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)) ??? This is ill formed Common Lisp. Presumably you mean: (defun twiddle-thumbs (thumb1 thumb2) (twiddle-thumbs thumb2 thumb1)) Which if called, say by: ... (twiddle-thumbs l-thumb r-thumb) ... will produce an infinite loop (and thus the "joke" part). BTW, Lisp _does_ require l-to-r argument evaluation in calls. > That really sums up the issue I was bringing up. The second function > in that particular pair of functions is probably defined by: I'm fairly sure you are referring to the pair of functions mentioned in HR's comment, but just so no one else gets confused: There is only one function in the Lisp given, not two. > 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. It's irrelevant as you (the compiler writer) simply arrange to have the arguments evaluated in the correct order and then passed. Here is an implementation of such a pair (in Lisp, since you can do this sort of stuff at the user/programmer level): (defmacro +one (l r) `(+ ,l ,r)) (defmacro +two (l r) (with-gensyms (ul ur) `(let ((,ul ,l) ; evaluate l (,ur ,r)); evaluate r (+one ,ur ,ul)))) This is semantically (at compilation level semantics) the same as: (defun +one (l r) (+ l r)) (defun +two (l r) (+one r l)) (declaim (inline +one +two)) What gets generated at a call in some code: (macroexpand-1 '(+one (sqrt 8) (expt 2 32))) ==> (+ (sqrt 8) (expt 2 32)) (macroexpand-1 '(+two (sqrt 8) (expt 2 32))) ==> (LET ((#:G87115 (SQRT 8)) (#:G87116 (EXPT 2 32))) (+ONE #:G87116 #:G87115)) (macroexpand '(+two (sqrt 8) (expt 2 32))) ; Fully expand ==> (LET ((#:G87135 (SQRT 8)) (#:G87136 (EXPT 2 32))) (+ #:G87136 #:G87135)) (+two (sqrt 8) (expt 2 32)) ==> 4.2949673e+9 So, arguments to both are always evaluated in the correct order, even though one compiles directly inline to a call of the other which is also compiled inline. No big deal. /Jon