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-01-29 15:52:13 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: <1075159458.149886@master.nyc.kbcfp.com> <1075225041.167448@master.nyc.kbcfp.com> <1075303237.975898@master.nyc.kbcfp.com> <9khh10pti0dn8gcp7f18ghptaifluj0fud@4ax.com> <1075390647.405841@master.nyc.kbcfp.com> <1075405582.982776@master.nyc.kbcfp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Date: Thu, 29 Jan 2004 23:52:13 GMT NNTP-Posting-Host: 12.72.183.4 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc05-news.ops.worldnet.att.net 1075420333 12.72.183.4 (Thu, 29 Jan 2004 23:52:13 GMT) NNTP-Posting-Date: Thu, 29 Jan 2004 23:52:13 GMT Organization: AT&T Worldnet Xref: archiver1.google.com comp.lang.ada:5071 Date: 2004-01-29T23:52:13+00:00 List-Id: On Thu, 29 Jan 2004 14:46:22 -0500, Hyman Rosen wrote: > I don't think you understand. As Ada stands now, it is perfectly > legal to write code which has unspecified results due to order of > execution. Actually, I do understand that. > Then some change > occurs in the environment, such as changing optimization level, > or changing platform, and now the compiler makes a different choice > and the code stops working. That's true, and not unique to this case. Not taking care of the size of Integer or integers can cause the same problem. So can threading code. > You cannot make the argument that raesonable care would prevent this. > That is the same argument that C programmers make for the compiler not > checking array bounds or pointer access, and Ada proponents roundly > reject such arguments. The difference is that with array bounds or pointer access, the compiler stops and says you're doing something wrong. This is more analogues to making array accesses silently wrap to prevent out of bound access; it may be what the programmer wanted, but a lot of times it won't be, and it will confuse maintainers who come afterwards. > Once > this is in place, then depending on the order of evaluation within an > expression will be no more problematic than depending on the order of > execution of a pair of statements, and will not be "buggy". I don't think a := f(x); b := g(x); c := a + b; is much better than c := f(x) + g(x); if f(x) and g(x) make silent changes to significant global state. But the first at least makes some indication that the order of operations is important. This is not proper coupling; I hardly see why Ada should go out of its way to support bad, unmaintainable code. >As for its > utility, I submit that code like this: > Point p := (x => ReadCoord, y => ReadCoord, z => ReadCoord); > is perfectly sensible once you forget that order of evaluation was ever > an issue and accept left-to-right as the natural way of things. Why is > this statement any worse than > cx, cy, cz : Coord := ReadCoord; > Point p := (x => cx, y => cy, z=> cz); I don't think it is. I don't really approve of the second statement, either. In any case, for I := 0.0 .. 2.0 step 0.25 loop could also be considered perfectly sensible, but most of the statements that extension would let in wouldn't be considered sensible.