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=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable 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 12:45:19 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!eusc.inter.net!newsfeed.stueberl.de!proxad.net!usenet-fr.net!enst.fr!melchior!cuivre.fr.eu.org!melchior.frmug.org!not-for-mail From: "Alexandre E. Kopilovitch" Newsgroups: comp.lang.ada Subject: Re: In-Out Parameters for functions Date: Sat, 24 Jan 2004 23:42:18 +0300 (MSK) Organization: Cuivre, Argent, Or Message-ID: References: <5ad0dd8a.0401240721.7682f2e1@posting.google.com> NNTP-Posting-Host: lovelace.ada-france.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: melchior.cuivre.fr.eu.org 1074976969 53675 80.67.180.195 (24 Jan 2004 20:42:49 GMT) X-Complaints-To: usenet@melchior.cuivre.fr.eu.org NNTP-Posting-Date: Sat, 24 Jan 2004 20:42:49 +0000 (UTC) To: comp.lang.ada@ada-france.org Return-Path: In-Reply-To: <5ad0dd8a.0401240721.7682f2e1@posting.google.com>; from Wojtek Narczynski at 24 Jan 2004 07:21:38 -0800 X-Mailer: Mail/@ [v2.44 MSDOS] X-Virus-Scanned: by amavisd-new-20030616-p5 (Debian) at ada-france.org X-BeenThere: comp.lang.ada@ada-france.org X-Mailman-Version: 2.1.3 Precedence: list List-Id: Gateway to the comp.lang.ada Usenet newsgroup List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Xref: archiver1.google.com comp.lang.ada:4786 Date: 2004-01-24T23:42:18+03:00 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. Then notice that the expressions often may be more complicated... something like this: F(A, B) * G(C, F(A, D)) + G(A, B) * F(C, G(A, D)) Add to that possible optimization issues, and probably you will see some reason to worry. Expressions with functions are too important part of a language like Ada, where various scientific formulas are used very often in typical applications. Therefore this part must be made safe enough and must respect mathematical viewpoint, which is naturally and commonly associated with formulas. > 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. > 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. Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia