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-03 17:54:48 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!wn11feed!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> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Date: Wed, 04 Feb 2004 01:54:48 GMT NNTP-Posting-Host: 12.72.183.224 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc05-news.ops.worldnet.att.net 1075859688 12.72.183.224 (Wed, 04 Feb 2004 01:54:48 GMT) NNTP-Posting-Date: Wed, 04 Feb 2004 01:54:48 GMT Organization: AT&T Worldnet Xref: archiver1.google.com comp.lang.ada:5205 Date: 2004-02-04T01:54:48+00:00 List-Id: On Tue, 03 Feb 2004 18:38:26 -0500, Hyman Rosen wrote: > David Starner wrote: >> The person who raised the argument and persists in arguing one side >> doesn't find the counter-arguments compelling. Shocking. > > There are plenty of times where I am convinced that a position I hold > has compelling counter-arguments. This is not one of them. I have yet > to hear why a deliberate ambiguity is better than a definite order. You're still far from an impartial judge. >> It violates the expectations of a maintaining programmer. > > So your point is that the language should increase the possibility of > error instead? This just makes no sense. It shouldn't make things right just because it can. It should make things right because they are logically right. >> To run into this problem, you'd usually be writing clumsy, hard to follow >> code that needs to be fixed, not patched at the language level. > > To belabor the point once more, > p : Point := (x => ReadCoord, y => ReadCoord, z => ReadCoord); > is not clumsy or hard to follow, merely wrong in the status quo. I have some pieces of code in response: for I in 0.0 .. 1.0 step 0.25 is not clumsy or hard to follow, merely wrong in the status quo. But making it right would bring in a lot of other stuff that won't work right. x : 0..1 := 0; function f : integer is begin x := 1 - x; return x; end f; r : integer := f - f; This isn't the clearest bit of code in the first place; on first glance, I want to say that r is 0. I have to read the implementation details of f to figure out what's going on. If it were x: 0..1 = 0; function f (z : integer) : integer is begin x := x - z; return x - z; end f; r: integer = f (x); then we would have stepped into another of Ada's constructive ambiguities, the fact that x may have been passed by copy or by reference. In a real-life program, the same code that produces the first will quite possibly run into the second problem. And if you don't, that doesn't mean that the maintainer, who doesn't understand the program as well, won't. >> Your solution papers over the problem > > My solution makes it no longer be a problem. In any real program, diddling with a bunch of global variables is likely to be hard to maintain and hard to reason about. Any thing that assumes that the interpretation order of a line is left to right is going to be adding sequence points where most languages don't have them and most code doesn't have them and is going to be surprising to a maintainer, and probably missed without comments. >> the array and pointer examples you keep bringing up. > > I haven't brought them up in the context of Ada, only C/C++. You've mentioned how they differ between Ada and C. But it's different to make something an loud error and make it legal. > True. But that doesn't mean that errors couldn't slip in anyway. Errors > that could be prevented at no cost to the programmer. And this could cause errors, by making things legal that are hard to reason about and actually program with. And there's a cost to the programmer, because it's a loss of an optimization opportunity and hence a slower program at the end.