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-01-24 13:57:09 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!priapus.visi.com!orange.octanews.net!news.octanews.net!news-out.visi.com!petbe.visi.com!news.maxwell.syr.edu!newsfeed.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: In-Out Parameters for functions Date: 24 Jan 2004 16:57:08 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <5ad0dd8a.0401240721.7682f2e1@posting.google.com> NNTP-Posting-Host: pip1-5.std.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1074981428 30184 192.74.137.185 (24 Jan 2004 21:57:08 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Sat, 24 Jan 2004 21:57:08 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: archiver1.google.com comp.lang.ada:4788 Date: 2004-01-24T16:57:08-05:00 List-Id: "Alexandre E. Kopilovitch" writes: > Wojtek Narczynski wrote: > > > This worry is unclear to me: > > > > >> And only one seems still valid: it is about complex > > >> expressions where a function call may be used as > > >> an actual argument for another function. > > > > I don't see how adding IN OUT arguments could make things worse in > > this matter. > > Look at this formulae: > > F(A) + G(A); > > If F is permitted to change value of A then the result of the formulae may > depend on order of computation. And this is obviously dangerous, because the > formulae looks as typical mathematical expression, where this effect usually > is not anticipated. That might be a good argument against side effects in functions, but Wojtek Narczynski is asking why, given that side effects in functions are allowed in Ada, is it damaging to allow side effects on 'in out' parameters. The F and G functions above might both write upon global variable X. How could writing upon parameter A be any worse? > > A function can have side effects on global state, it can > > have side effects on its IN paramerters (by using the Rosen trick). > > Yes, but if a programmer produces/uses side effects on global state in a > function and especially if he changes IN parameters by any trick, he at least > knows that he is doing irregular things - and takes responsibilty for that. > Providing IN OUT parameters for functions we remove this mental > warning/deterrent. The person reading the body of F or G can of course know what's going on. But the person reading the expression "F(A) + G(A)" has no idea. Allowing 'in out' parameters would not change that fact. > > I just don't see how documenting those side effects in the function > > specification could make things worse. > > The problem is that it may be not enough to document those possible side > effects in the function's specification - and the above point is exactly > about that. By requiring it to be documented in call site also, we ensure > that the caller is aware of possible side effect there and agreed with it. I agree that requiring syntax at the call site to indicate side effects would be a good idea. But that's not an argument against 'in out' parameters of functions. - Bob