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=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable 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-28 05:24:54 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-01!sn-xit-09!supernews.com!pln-w!lotsanews.com!newsfeed.icl.net!proxad.net!freenix!enst.fr!melchior!cuivre.fr.eu.org!melchior.frmug.org!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: left-to-right (was In-Out Parameters for functions) Date: 28 Feb 2004 08:22:20 -0500 Organization: Cuivre, Argent, Or Message-ID: References: <40236C0B.E988E003@0.0> <1077634311.254581@master.nyc.kbcfp.com> <3c0u3054mganvifajj3g6jealh07qoi1h7@4ax.com> NNTP-Posting-Host: lovelace.ada-france.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: melchior.cuivre.fr.eu.org 1077974567 84118 212.85.156.195 (28 Feb 2004 13:22:47 GMT) X-Complaints-To: usenet@melchior.cuivre.fr.eu.org NNTP-Posting-Date: Sat, 28 Feb 2004 13:22:47 +0000 (UTC) To: comp.lang.ada@ada-france.org Return-Path: In-Reply-To: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at ada-france.org X-BeenThere: comp.lang.ada@ada-france.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Gateway to the comp.lang.ada Usenet newsgroup" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Xref: archiver1.google.com comp.lang.ada:5921 Date: 2004-02-28T08:22:20-05:00 Dmitry A.Kazakov writes: > On 27 Feb 2004 09:07:12 -0500, Stephen Leake > wrote: > > >You have made two statements: > > > >1) "the programmer must ensure the code is valid for any order of > > evaluation". > > > >2) "it is difficult to check if things do depend on order of > > evaluation" > > > >The second is paraphrased, but I believe it captures what you said > >above. > > > >These statements seem at odds, to me. You are requiring the programmer > >to do something that is difficult. > > It is like constructive vs. existence proof. (:-)) The programmer need > not to check things, because he a priory knows what they are. This > knowledge comes from the application domain. If he does not have it, > he should better search for other occupation. But the compiler knows > nothing, so it should check, not assume as Hyman Rosen proposes. Ok, that makes sense. But _this_ programmer would appreciate some help from the language. But I guess that's really the domain of SPARK, not Ada. > >> >Why is that better? The goal is to have code that works (meaning > >> >produces correct results :), on all compilers/platforms. > >> > >> But the code has some semantics it implements, at least I hope it is > >> so (:-)). This semantics is either order-dependent or not. That does > >> not depend on platform. The goal is to implement that semantics. The > >> rest does Ada. > > > >Right. And _if_ the semantics happens to be order-dependent, then to > >be portable, the same order must be used on every compiler/platform. > > Then the semantics has to be *explicitly* expressed in the code, as an > important part of implementation. The code reader should clearly see > it, and say, aha! Yes! the code should certainly express the desired semantics! I'm not clear what your point here is. > >So we need to talk about why you believe this to be the case - we > >cannot simply say "yes, you are right". > > We cannot, because it would mean that there are no cases where the > semantics is order-independent. Why is that a problem? Matrix multiply semantics is order-dependent (not evaluation order, but multiply order). Again, I'm not getting your point. > >> >But you haven't answered my question. Is there, in actual fact, any > >> >compiler that actually does these optimizations? > >> > >> Randy Brukardt gave one example. However I would like to stress that > >> optimization and implementation freedom is only one, though important > >> argument. Software design practice is no less important. Fixing order > >> not imposed by the semantics, and thus an arbitrary order, is that > >> sort of premature optimization Knuth wrote about. My concern is that > >> fixing an arbitrary order would bless bad software design in favor of > >> getting results now. > > > >But it is only bad _because_ it prevents optimization. At least, that > >is the only argument I have heard so far. You do _not_ give a > >different argument in this paragraph; you just repeat the optimization > >one. > > > >What _other_ reason is there? > > Occam's razor priciple - to have code valid under possibly least > strong assumtions. Weaker they are, higher is the code quality. Then we should all be using SPARK. There is a trade off to be made; readability vs portability vs efficiency. Ada 95 made one choice for the trade off; we are discussing other possible choices. -- -- Stephe