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-25 01:11:34 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: In-Out Parameters for functions Date: Wed, 25 Feb 2004 10:21:14 +0100 Message-ID: References: <1075851506.238480@master.nyc.kbcfp.com> <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> 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 1077700292 54070603 I 212.79.194.116 ([77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:5784 Date: 2004-02-25T10:21:14+01:00 List-Id: On 24 Feb 2004 19:44:12 -0500, Stephen Leake wrote: >David Starner writes: > >> On Tue, 24 Feb 2004 09:51:44 -0500, Hyman Rosen wrote: >> > As I have said over and over again, the problematic case is when >> > it matters, and no one notices, and the compiler happens to do >> > what you want. Then a change in environment could result in the >> > order changing, and all of a sudden, code mysteriously breaks. >> >> And the life and death case is when it matters and the compiler does >> what you want, and then maintainers change something, and after they >> discover there were uncommented, incredibly subtle order issues, they >> go out to kill the original smart-ass programmer. > >I think Hyman has two valid points: > >1) if the language specified left-to-right order, there would never be > a need to "kill the original smart-ass programmer" But also, if the language disallowed side-effects when there could be more than one order. I prefer the second, provided that the term "side-effect" should be formally defined by the language and visible from the specifications. >2) Does anyone have a real example of a compiler taking advantage of > the evaluation order freedom to speed up a program? The question is what gets lost if an evaluation order is fixed. I gave an example earlier: for I in A'Range loop Sum := Sum + A (I) + B (B'First + I - A'First); ... Here with left-to-right order the compiler cannot optimize neither the array index of B, nor can it increment Sum by adding A()+B(). Well, these optimizations could be made possible if the compiler might prove that the result does not depend on the order. That could be quite difficult to formally define, especially regarding numeric exceptions and floating-point accuracy stuff. Even more difficult it would be check. 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! So the bottom line, IMO, 1 makes no sense. >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. >I have not heard anyone respond to 2), which is supposedly the reason >the freedom is there. If no compiler actually takes advantage of it, >it's not worth having. > >I don't think there's much chance Ada will change in this area; it >would cost more to change the documentation than it is worth. > >But we can at least be honest about it! -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de