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-28 02:09:06 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 <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: In-Out Parameters for functions
Date: Wed, 28 Jan 2004 11:16:51 +0100
Message-ID: <8a0f10p024nccb9iknohtcj12g82h38bpl@4ax.com>
References: <uhdyhq1zl.fsf@acm.org>
 <mailman.39.1075236553.2270.comp.lang.ada@ada-france.org>
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 1075284545 26498000 212.79.194.116 ([77047])
X-Newsreader: Forte Agent 1.8/32.548
Xref: archiver1.google.com comp.lang.ada:4983
Date: 2004-01-28T11:16:51+01:00
List-Id: <comp.lang.ada>

On Tue, 27 Jan 2004 23:48:58 +0300 (MSK), "Alexandre E. Kopilovitch"
<aek@VB1162.spb.edu> wrote:

>Stephen Leake wrote:
>
>> > 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 :).
>
>"Random" is very special case, in which an intention is quite opposite to what
>is common in normal "regular" circumstances. In "regular" circumstances we want
>the same result

And we have the *same* result, a realization of a *random* number. It
indeed does not depend on the input parameters (ideally). A program
using random numbers in turn becomes random in the sense that its code
and results are random. So we could treat Random as a constant, in a
random program. Of course Random is pseudo random, so it needs a
parameter, which is an implementation detail.

BTW, amusing A.5.2:

   procedure Reset (Gen : in Generator);  -- Reset an *IN* parameter!

but consistent with the design choice. Interestingly, that a true
Random, taking numbers from a hardware, should indeed have "in
Generator", provided, that it does not destroy the hardware just by
reading the values. (:-))

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de