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-25 01:33:29 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!wn13feed!worldnet.att.net!bgtnsc05-news.ops.worldnet.att.net.POSTED!not-for-mail From: David Starner Subject: Re: In-Out Parameters for functions User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity. (Debian GNU/Linux)) Message-Id: Newsgroups: comp.lang.ada References: <1075390647.405841@master.nyc.kbcfp.com> <1075405582.982776@master.nyc.kbcfp.com> <1075482385.142744@master.nyc.kbcfp.com> <1075732402.294581@master.nyc.kbcfp.com> <1075741279.952497@master.nyc.kbcfp.com> <16nu1099ekujjbpe9dqvs3noi9sdcfja6e@4ax.com> <1075817212.745748@master.nyc.kbcfp.com> <1075824683.769215@master.nyc.kbcfp.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Date: Wed, 25 Feb 2004 09:33:28 GMT NNTP-Posting-Host: 12.72.70.248 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc05-news.ops.worldnet.att.net 1077701608 12.72.70.248 (Wed, 25 Feb 2004 09:33:28 GMT) NNTP-Posting-Date: Wed, 25 Feb 2004 09:33:28 GMT Organization: AT&T Worldnet Xref: archiver1.google.com comp.lang.ada:5785 Date: 2004-02-25T09:33:28+00:00 List-Id: On Tue, 24 Feb 2004 19:44:12 -0500, Stephen Leake wrote: > 1) if the language specified left-to-right order, there would never be > a need to "kill the original smart-ass programmer" If it got changed in maintenance, and introduced a bug because no one saw the hidden dependency, then there would be. > 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_. But it doesn't change the meaning of much clear, unsurprising code. Most of the examples depend on hidden state. The rest depend on I/O. Neither occur much in clear, unsurprising code. (Okay, so I/O is necessary in programs. But the examples using I/O can be rewritten not to use this, and are usually pretty obvious.) > 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! I think part of it is language philosophy. Ada is not C, but it's not Java, either. Ada's goal is not to make every program run exactly the same everywhere. Perhaps the supposed efficiency goals aren't achieved by this choice, but reversing the choice, and helping some marginal code become legal, isn't a huge win in the terms of Ada's choices.