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-07 06:25:00 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!zeus.visi.com!priapus.visi.com!orange.octanews.net!news.octanews.net!news-out.visi.com!petbe.visi.com!skynet.be!freenix!enst.fr!melchior!cuivre.fr.eu.org!melchior.frmug.org!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: Certified C compilers for safety-critical embedded systems Date: 07 Jan 2004 09:21:07 -0500 Organization: Cuivre, Argent, Or Message-ID: References: <3fe00b82.90228601@News.CIS.DFN.DE> <5802069.JsgInS3tXa@linux1.krischik.com> <1072464162.325936@master.nyc.kbcfp.com> <1563361.SfB03k3vvC@linux1.krischik.com> <11LvOkBBXw7$EAJw@phaedsys.demon.co.uk> <3ff0687f.528387944@News.CIS.DFN.DE> <1086072.fFeiH4ICbz@linux1.krischik.com> <3ff18d4d.603356952@News.CIS.DFN.DE> <1731094.1f7Irsyk1h@linux1.krischik.com> <3ff1b8ef.614528516@News.CIS.DFN.DE> <3FF1E06D.A351CCB4@yahoo.com> <3ff20cc8.635997032@News.CIS.DFN.DE> <3ff9df16.30249104@News.CIS.DFN.DE> <3FFC0201.6020303@noplace.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 1073485282 13880 80.67.180.195 (7 Jan 2004 14:21:22 GMT) X-Complaints-To: usenet@melchior.cuivre.fr.eu.org NNTP-Posting-Date: Wed, 7 Jan 2004 14:21:22 +0000 (UTC) To: comp.lang.ada@ada-france.org Return-Path: In-Reply-To: <3FFC0201.6020303@noplace.com> 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:4172 Date: 2004-01-07T09:21:07-05:00 Marin David Condic writes: > What exactly would be the meaning of: > > A := Func_X (A) + Func_Y (A) ; > if functions had in-out parameters and A could be modified while > evaluating the RHS? Obviously, this is erroneous code, since the result depends on the order of evaluation. Note that it is legal Ada now, if A is an access parameter. It is similarly erroneous if either Func_X or Func_Y have other mutually-dependent side effects. Ada usually tries to eliminate the possibility of such erroneous code. But given all the ways this statement can be erroneous, I see very little gain from forbidding "in out". I guess that's the point of disagreement; how much gain or cost there is in forbidding "in out". > Sure, the functions *could* modify A if they > had visibility to the right scope, but how often does someone do > that in real-world use? All the time in my code, because I need to write reentrant code that has state. The canonical example is a random number generator: function Random (Gen : in out Generator) return Float; "Obviously", this should be a function (the C and Ada standards say so :). Also "obviously", it needs to modify the state of the generator. Not so obviously, that state needs to be stored in the parameter, so I can call Random from several different threads. Currently, in non-tricky, legal Ada 95, we cannot simultaneously satisfy all of the above statements. The only one I'm free to change is the first one; subprograms that modify state and are reentrant must be procedures, not functions. (I include using "access" instead of "in out" as "tricky" code). All of the Ada 95 implementations must resort to "tricks" to implement the standard Random. That seems "totally bogus" to me :). > The current style - while not guaranteeing a lack of side effects - > tends to discourage it and leads to more easily comprehended code. Marginally more comprehendable, in some cases. Marginally less comprehendable, in other cases. This is really a moot point, since we have access parameters. Why is making A "access" better than making A "in out"? The parameter mode is supposed to indicate whether the parameter is modified or not. It is _not_ supposed to indicate the parameter passing mechanism! Using "access" instead of "in out" is a form of lying to the user; it reduces comprehension. > I don't understand what the headache is here anyway. If one wants to > modify parameters, use a procedure. That is always possible. But why should I not have the choice of using a function, if it fits the application better? Why is Random a function? > If one wants some kind of > math-oriented thingie to return a result, use a function. But I want a function that modifies state in a reentrant way, like Random does. > Only interfacing to squirly languages like C seems to be an issue - > and I think that ought to be a difficult and painful thing to > discourage it from happening. :-) Interfacing with C always requires a pragma, so 'pragma Valued_Procedure' is perfectly reasonable here. I agree that is _not_ an argument for "in out" in functions. -- -- Stephe