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-26 23:36:26 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.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: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: In-Out Parameters for functions Date: 27 Jan 2004 02:34:06 -0500 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 1075188865 22596 80.67.180.195 (27 Jan 2004 07:34:25 GMT) X-Complaints-To: usenet@melchior.cuivre.fr.eu.org NNTP-Posting-Date: Tue, 27 Jan 2004 07:34:25 +0000 (UTC) To: comp.lang.ada@ada-france.org Return-Path: In-Reply-To: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 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:4880 Date: 2004-01-27T02:34:06-05:00 "Alexandre E. Kopilovitch" writes: > 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. Hmm. Let F be Sqrt (Ada.Numerics.Float_Random.Random), and G be Ada.Numerics.Float_Random.Random. Then we see that Ada _requires_ the behavior you are describing. So it's clearly a Good Thing :). Which is pretty ironic, since one reason Ada.Numerics.Float_Random.Random is defined as a function is to satisfy some notion of "mathematical purity". The closest the AARM comes to saying that is in AARM A.5.2: 32.b Reason: The requirement for a level of indirection in accessing the internal state of a generator arises from the desire to make Random a function, rather than a procedure. Given that Ada _requires_ that users be allowed to write expressions with the order dependency you describe, what would be wrong with defining Ada.Numerics.Float_Random.Random with parameter mode "in out"? Or, to be fully consistent, Ada.Numerics.Float_Random.Random should be a procedure. I'll have to remember to never add two functions of a random number together in one expression, if I want truly portable results. I don't think I actually do that, anyway; there are usually intermediate values when a final result depends on more than one random number. But I suspect casual users of random numbers will not be worried about precisely repeatable results from different compilers for this kind of expression. Users will always be able to shoot themselves in the foot. The language should help them avoid that, but it cannot prevent it. The language needs to find a reasonable balance between prevention of bad effects and expressive power. In this particular case I think Ada strayed too far to the "prevention" side. C++, on the other hand, is too far on the "expressive" side in general. -- -- Stephe