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-06 16:53:52 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: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: Certified C compilers for safety-critical embedded systems Date: 06 Jan 2004 19:51:43 -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> 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 1073436715 13805 80.67.180.195 (7 Jan 2004 00:51:55 GMT) X-Complaints-To: usenet@melchior.cuivre.fr.eu.org NNTP-Posting-Date: Wed, 7 Jan 2004 00:51:55 +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:4161 Date: 2004-01-06T19:51:43-05:00 "Jean-Pierre Rosen" writes: > > "Stephen Leake" wrote in message > > news:mailman.212.1073342204.31149.comp.lang.ada@ada-france.org... > > Apparently there were some people on the design team for Ada 83 who > > thought "function" meant "no side effects", and want to "enforce" > > that. Of course, functions can have side effects; now they just have > > to lie about it! > I've seen this argument quite often (especially by RBKD), but it is > totally bogus. Hmm. You must be using some different meanings for the words "totally bogus" than I do. > Nobody claimed that functions should not have side effects, but only > that functions compute a result given some parameters and the global > state of the program. That's what procedures do as well; what's the difference? Oh, one of the "out" parameters to a function is called the "result". Why should that matter? > It was felt that it was OK for a function to modify the global > state, but modifying the parameters would be surprising and > error-prone. Surprising to you, perhaps. Not to me! It is surprising to me that I _can't_ have "in out" in functions. So the argument is _not_ _totally_ bogus. A little bogus, perhaps? I'd prefer to say the argument is not universally accepted, or more accuratly, not accepted by a majority of the Ada 83 and 95 teams. > BTW, Ada79 had functions that were required to not have side > effects, and value returning procedures that did not have this > constraint. This was felt to be too extreme (or maybe difficult to > enforce) and the current solution to be an acceptable trade-off. I understand that was the decision reached. Obviously, I'd prefer the Ada79 approach. Or provide a pragma (like Pure) that says "this function has no side effects". I'm having a hard time understanding what the downside of permitting me to use "in out" in functions is, for those who don't want them. It doesn't cost them anything! We could give them a compiler switch that forbids them if they want it. -- -- Stephe