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=-0.9 required=5.0 tests=BAYES_00,FROM_NUMERIC_TLD autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,31c63f07e48d5471 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-02-21 01:53:28 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!nntp.abs.net!uunet!dca.uu.net!lore.csc.com!baen1673807.greenlnk.net!baen1673807!not-for-mail From: Stuart Palin Newsgroups: comp.lang.ada Subject: Re: Ada to 'C' parameter passing problem Date: Fri, 21 Feb 2003 09:53:15 +0000 Organization: BAE SYSTEMS Avionics Message-ID: <3E55F70B.A254EAF@0.0> References: <1ec946d1.0302191836.743eab91@posting.google.com> NNTP-Posting-Host: 20.44.240.33 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: lore.csc.com 1045821204 27324 20.44.240.33 (21 Feb 2003 09:53:24 GMT) X-Complaints-To: abuse@news.csc.com NNTP-Posting-Date: Fri, 21 Feb 2003 09:53:24 +0000 (UTC) X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en X-Original-NNTP-Posting-Host: rc2966.rochstr.gmav.gecm.com X-Original-Trace: 21 Feb 2003 09:51:55 GMT, rc2966.rochstr.gmav.gecm.com Xref: archiver1.google.com comp.lang.ada:34334 Date: 2003-02-21T09:53:15+00:00 List-Id: Simon Wright wrote: > I recall Robert Dewar saying that he thought that restricting > functions to "in" (or access) parameters was a Bad Idea -- Ada is a > programming language, not a mathematical abstraction, and there is > nothing in Ada to stop a function modifying global state. (Praise be, > say I). But Robert got outvoted during the Ada 9X process. I would think that there are [at least] a couple of conflicting inputs to this. 1) By allowing functions to have side-effects you create problems related to expression evaluation order - which introduces an additional source of compiler dependencies. 2) Modifying global state is not prevented by the language rules. But this would be so difficult to do within the constraints (or freedoms) of other language objectives (principally the separate compilation of specification and body and the hiding of internal behaviour. Note that SPARK addresses the issue of purity by ensuring the effect on global state is made visible at the specification level). Point 1 suggests it is a bad idea, point 2 shows the language can not be entirely pure on this matter. Would allowing function parameters to be in out/out be encouraging a risky practice, or a recognition that the language can not fully police the concept. I favour the existing language rules which at least do not 'encourage' the risks that might arise through functions with side-effects. [RD does not usually make unconsidered statements, so I would be interested in reading his line of arguments. Is it available somewhere convenient?] -- Stuart Palin