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-09 15:40:37 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!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 (was: Re: Certified C compilers for safety-critical embedded systems Date: Sat, 10 Jan 2004 02:38:17 +0300 (MSK) Organization: Cuivre, Argent, Or Message-ID: References: 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 1073691502 55789 80.67.180.195 (9 Jan 2004 23:38:22 GMT) X-Complaints-To: usenet@melchior.cuivre.fr.eu.org NNTP-Posting-Date: Fri, 9 Jan 2004 23:38:22 +0000 (UTC) To: comp.lang.ada@ada-france.org Return-Path: In-Reply-To: ; from Robert A Duff at 09 Jan 2004 17:30:43 -0500 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:4285 Date: 2004-01-10T02:38:17+03:00 Robert A Duff wrote: > >... Except that possibly it casts into doubt what happens in an > > expression loaded with function calls where one used to be able to > > assume that the parameters were not being modified. With in-out you'd > > have to know the parameter modes before you could interpret what the > > expression was doing. > > That's a good point, too. You can't get any advantage out of having > side-effect-free functions unless you (the reader of the program) can > somehow *know* that they are side-effect-free. > > I would be in favor of marking 'in out' and 'out' with some syntax at > the call site. >... Let me put here two my messages to Ada-Comment, which were sent there more than a year ago (November 2002, I think) - they were exactly about this topic, and the second of them even contains concrete proposal for syntax mark at the call site. ----- 1 ------------------------------------------------------------------ >I do not believe it can possibly get consensus support. Lacking a list of arguments against IN OUT in functions, I only guess that perhaps following restrictions will satisfy the opponents: 1) function with IN OUT parameter cannot be operator (and cannot be renamed to operator) 2) actual argument for IN OUT formal parameter cannot be used in any place within the whole statement. >functions aren't really functions in Ada, no matter how much >some people :-) would like to think that. Well, even in pure mathematics functions sometimes have effectively OUT parameters - when used in equations (with a suitable form of equation it is possible to simulate IN OUT parameter also). ----- 2 ------------------------------------------------------------------ >> perhaps following restrictions will satisfy the opponents: >> >> 1) function with IN OUT parameter cannot be operator (and cannot be renamed >> to operator) >> 2) actual argument for IN OUT formal parameter cannot be used in any place >> within the whole statement. > >You guess completely wrong, Not so completely - it appears that the above restrictions actually address some of those old objections. > you should really make an effort to dig up >the old threads on this subject. I just did that. I found 5 files in old Ada-Comment archive: http://archive.adaic.com/standards/95com/mrtcomments/ namely: 94.0817, 94.0818, 94.0819, 94.0821, 94.0907, relevant to the OUT parameters for functions. I assume that those files cover that old discussion (if I missed something important and there are other relevant files then I hope somebody will point me at them). It appears that most often stated objection against lifting the restriction (OUT/IN OUT parameters for functions) was simply "too late" (meaning some schedule of the Ada9X project) - I found 3 persons saying that. Obviously, today that kind of objection is "void and null". Among the essential objections some are fully covered by the proposed restrictions (above). Another is about totally unspecified fantom danger (it is about overloading). 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 believe that that objection will be covered by the following 3rd rule for IN OUT parameters for functions: 3) in a function call, an actual argument that corresponds to IN OUT formal parameter must be a variable, and must be preceeded by the keyword VAR. For example: X := Random(var Y); With this rule any confusion becomes improbable, and readability flourishes. >The objection is that IN OUT parameters are fundamentally inappropriate >for functions. Apparently that "fundamentally inappropriate" disintegrates into several objections, and they are covered by the proposed 3 rules - I repeat them here together: 1) function with IN OUT parameter cannot be operator (and cannot be renamed to operator) 2) actual argument for IN OUT formal parameter cannot be used in any place within the whole statement. 3) in a function call, actual argument that corresponds to IN OUT formal parameter must be a variable, and must be preceeded by the keyword VAR. -------------------------------------------------------------------------- Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia