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-27 09:01:27 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!tar-atanamir.cbb-automation.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: left-to-right (was In-Out Parameters for functions) Date: Fri, 27 Feb 2004 18:11:18 +0100 Message-ID: References: <40236C0B.E988E003@0.0> <1077634311.254581@master.nyc.kbcfp.com> <3c0u3054mganvifajj3g6jealh07qoi1h7@4ax.com> NNTP-Posting-Host: tar-atanamir.cbb-automation.de (212.79.194.116) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de 1077901286 56226634 I 212.79.194.116 ([77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:5902 Date: 2004-02-27T18:11:18+01:00 List-Id: On 27 Feb 2004 09:07:12 -0500, Stephen Leake wrote: >Dmitry A.Kazakov writes: > >> Exactly, they should not! People have to write programs so that they >> would be valid for any allowed order. If they don't the code is >> broken. In my view it is broken *even* if the language defined >> implicit order is the one assumed by the programmer. >> >> My point is: either 1) the order is specified explicitly by the >> programmer, or 2) the code is valid for any order. > >Hmm. You missed my point. Let me try again. > >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. >> >> But finally, if all that could be achived, then the compiler will be >> >> capable to simply detect that different orders give different >> >> results, and threat it as an error. Much better than fixing an >> >> arbitrary order! >> > >> >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! >That is not possible in Ada 95; it would be possible in "left-to-right >Ada 95". > >> > If I only >> >have to prove that one evaluation order is correct, that is easier >> >than if I have to think about many evaluation orders. >> >> True. Weaker the precondition, harder to write the code. It is quite >> easy to write sqrt provided that the only valid value of the argument >> is 0. Alas, that would be not what people understand under sqrt. From >> software design point of view it is always worth to try to write >> order-independent code, like one with a weakest precondition. The >> opposite should be treated rather as an exception. > >You are assuming the consequence of this argument :). > >The point is that (perhaps) it is _not_ always worth writing >order-independent code. Of course, in all cases when the semantics is order-dependent. >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. >> >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. >Software design practices such as "write order-independent code" are >useful simplifications of complex arguments; they allow programmers to >get on with day-to-day work without spending lots of time thinking >about arcane compiler implementation issues :). Yep, that is what I am afraid of! (:-)) >However, in _this_ discussion, we are trying to elucidate the complex >argument behind this particular software design practice, in order to >decide if it is still valid. > >> >> >Ada is supposed to be about clear, unsurprising code. Subtle order >> >> >issues are just that - "subtle". If the language _could_ make them a >> >> >non-issue, at very little cost, I think it _should_. >> >> >> >> Right, the present situation is not good. But IMO the solution lies in >> >> introducing formally pure functions and imposing limitations on use of >> >> impure functions (and procedures with results) in expressions. >> > >> >That's way more work than simply requiring left-to-right, and >> >therefore far less likely to happen. >> >> AFAIK Ravescar profile would be a part of the standard. > >Yes, the Ravenscar profile will (probably :) be standardized in Ada >0Y. But that will be as an restriction pragma, allowing users to >choose a subset of Ada. Like one with pure functions... >> A time may come when some SPARK ideas will be evaluated too. > >If you mean that the SPARK language will be added as another optional >Ada standard, I doubt it. SPARK may become a standard on its own. I meant measures to make more things statically checkable. SPARK is one possible of many ways. In many cases it is too restrictive. So probably one should have many levels of restrictions. -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de