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 15:39:14 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!nntp.abs.net!uunet!dca.uu.net!ash.uu.net!spool.news.uu.net!not-for-mail Date: Tue, 03 Feb 2004 18:38:26 -0500 From: Hyman Rosen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: In-Out Parameters for functions 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> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Organization: KBC Financial Products Message-ID: <1075851506.238480@master.nyc.kbcfp.com> Cache-Post-Path: master.nyc.kbcfp.com!unknown@carrots.nyc.kbcfp.com X-Cache: nntpcache 3.0.1 (see http://www.nntpcache.org/) NNTP-Posting-Host: 204.253.250.10 X-Trace: 1075851506 6491 204.253.250.10 Xref: archiver1.google.com comp.lang.ada:5202 Date: 2004-02-03T18:38:26-05:00 List-Id: 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. > 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. I really get the sense that people are clinging desperately to "we've always done it this way". > 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. > Your solution papers over the problem My solution makes it no longer be a problem. > the array and pointer examples you keep bringing up. I haven't brought them up in the context of Ada, only C/C++. > You have to test the production version of your software already. You > never know what different switches will do to your code whether so > authorized by the standard or not. True. But that doesn't mean that errors couldn't slip in anyway. Errors that could be prevented at no cost to the programmer. > All those arguments have to do with the writing of code in Ada. I don't find that compelling :-)