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-27 01:14:22 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!tar-atanamir.cbb-automation.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: In-Out Parameters for functions Date: Tue, 27 Jan 2004 10:22:02 +0100 Message-ID: References: NNTP-Posting-Host: tar-atanamir.cbb-automation.de (212.79.194.116) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de 1075194861 25448815 212.79.194.116 ([77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:4888 Date: 2004-01-27T10:22:02+01:00 List-Id: On Mon, 26 Jan 2004 23:19:49 +0300 (MSK), "Alexandre E. Kopilovitch" wrote: >Dmitry A. Kazakov wrote: > >> >Therefore, IN OUT parameters in functions will not be worse than the ability >> >of functions to change global variables if we forbid use of such functions in >> >expressions, that is: >> > >> > If at least one parameter of a function is in IN OUT mode then the function >> > cannot be used in a compound expression. This function's call must always >> > constitute the whole RHS of an assignment. >> > >> >or less restrictive rule: >> > >> > If at least one parameter of a function is in IN OUT mode then in any >> > expression in which this function is called all other calls may be for >> > parameterless functions only. >> >> What about: >> >> F(X) and then F(X) > >Naturally, forbidden. Perhaps the wording of my (above) "less restrictive rule" >was not good enough, but I meant that "all other calls" includes other calls >of the mentioned function (which has an IN OUT parameter), and that the meaning >is entirely static, not dynamic. So, probably at least one correction should >be made in this rule - replacing "calls" by "references": > > If at least one parameter of a function is in IN OUT mode then in any > expression in which this function is called all other references may be > for parameterless functions only. This limitation has no sense for short-circuit operations. >Well, I leave the exact wording of the rule to native English speakers -;) . > >> The rule, if any, should prevent using an object in IN OUT mode in an >> expression where the evaluation order is not specfied by the language. > >Yes, certainly. And I'd forbid that even if that order IS specified but may be >non-obvious... actually I'd forbid that in all cases where that order can >matter at all - for anything. The problem is that this cannot be checked in a reasonable way because of aliasing. And I am afraid that for Ada newcomers the effect would be even more frustrating than in the case accessibility checks. If we had pure functions there could be a more attractive (?) aternative: to fix the evaluation order if a non-pure function gets involved. >> Looks much like the aliasing problem: >> >> procedure Foo (X, Y : in out Object) is >> begin >> X := F(X) + F(Y); -- Is this legal? >> Foo (X, X); -- And this? >> end Foo; > >Perhaps legal, but awfully wrong -;) A bound error? (:-)) -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de