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,31c63f07e48d5471 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-02-21 10:17:06 PST Message-ID: <3E566C11.1020904@cogeco.ca> From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Ada to 'C' parameter passing problem References: <1ec946d1.0302191836.743eab91@posting.google.com> <3E55F70B.A254EAF@0.0> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 21 Feb 2003 13:12:33 -0500 NNTP-Posting-Host: 198.96.47.195 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1045851153 198.96.47.195 (Fri, 21 Feb 2003 13:12:33 EST) NNTP-Posting-Date: Fri, 21 Feb 2003 13:12:33 EST Organization: Bell Sympatico Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!snoopy.risq.qc.ca!torn!webster!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Xref: archiver1.google.com comp.lang.ada:34358 Date: 2003-02-21T13:12:33-05:00 List-Id: Stuart Palin wrote: > 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. ... > 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 I can see that there is value in being able to say, while reading somebody's code: "this is a function, hence there is no state change here." But, we all know that this isn't enforced in the language, beyond the trivial aspect of restricting parameter use (even that is inconsistent, because access parameters are permitted). The function being called can be changing state within the package it is defined in, or even calling other functions and procedures that change states in other places to boot. So this idea cannot be trusted to begin with. So with my own personal "practical hat" on, I'd have to side with those in favour of opening up the function arguments to permit in/out, out parameters. The present arrangement only _discourages_ side effects, and perhaps this is something that some feel is worth maintaining. If it becomes a requirement to provide purely functional calls (ie. with no side effect), then I think it is mandatory for some other mechanism to exist and have it enforced by the compiler, IMHO. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg