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,ce0900b60ca3f616 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-11-04 09:24:54 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!fu-berlin.de!uni-berlin.de!ppp-1-150.cvx2.telinco.NET!not-for-mail From: "Nick Roberts" Newsgroups: comp.lang.ada Subject: Side-Effects in Functions [Rosen Trick] Date: Sun, 4 Nov 2001 17:17:08 -0000 Message-ID: <9s3tl3$111hco$1@ID-25716.news.dfncis.de> References: <9rti6v$hcu$1@news.huji.ac.il> <1EyE7.10050$xS6.13527@www.newsranger.com> <9rue9f$j4t$1@nh.pace.co.uk> <9ruiet$kqg$1@nh.pace.co.uk> <3BE3235D.E292B890@boeing.com> <3BE35498.9F6381A2@acm.org> <9s230d$107b5a$2@ID-25716.news.dfncis.de> <5ee5b646.0111040507.5ca7ea23@posting.google.com> NNTP-Posting-Host: ppp-1-150.cvx2.telinco.net (212.1.140.150) X-Trace: fu-berlin.de 1004894692 34653592 212.1.140.150 (16 [25716]) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Xref: archiver1.google.com comp.lang.ada:15765 Date: 2001-11-04T17:17:08+00:00 List-Id: "Robert Dewar" wrote in message news:5ee5b646.0111040507.5ca7ea23@posting.google.com... > "Nick Roberts" wrote in message news:<9s230d$107b5a$2@ID-25716.news.dfncis.de>... > > > PS: Why? Because functions should not have side-effects (in a language like > > Ada). > > You present this as a kind of obvious ab initio fact, but > it is nothing of the kind. I was hoping that it would be obvious that I was putting this point in a deliberately polemical style. I am merely stating my own strongly held belief on this subject, based on perfectly good reasoning, as well as the consensus of programming wisdom. > Here are the facts: > ... > There was some attept early on to consider trying to stop > functions from having side effects, and indeed I think one > published early version of Ada distinguished functions and > value returning procedures, or at least that was discussed. I'm glad this didn't happen, because, as mentioned in my previous post, there are occasions -- such as debugging, profiling, auditing -- when it is useful for a function to have a side-effect, and forcing the programmer to convert it to a procedure -- and thus all calls on it to procedure calls -- would be wholly unjustified. > But such attempts were firmly rejected, and the decision > was that there are situations where it makes perfectly good > sense for functions to have side effects, and an absolute > rule prohibiting them is in the same not-well-thought-out > category as absolute rules against use clauses, goto statements, > unchecked conversion, and various other very > useful features of Ada. Useful does not mean that they should be used > all the time, or misused, just that they have some legitimate use. I agree there. > Another important factor is that other languages agree with > Ada that functions should be allowed to have side effects. > In particular C takes this viewpoint, and side effects in > functions are common in C, including side effects in calls > to standard functions in the C library. The fact that the C language permits something, or that C programmers do a particular thing, is surely no recommendation that Ada programmers should do the same! > Now in Ada, the rule for functions is a bit odd: > > Side effects from access to global variables - permitted > Side effects from modifying access type args - permitted > Side effects from in out parameters - prohibited These rules may seem a little odd, but they pertain to what Ada allows programmers to do, not what Ada programmers should do. My point was entirely about what Ada programmers should do. > I have never understood the rationale for this inconsistent > design. The rationale is simple and well-known Robert! Good grief, every Ada textbook on the planet has an example of how side-effects in functions can introduce subtle and pernicious bugs (especially on porting). Must I really repeat these? > Most annoyingly, the natural translation of a * arg in a > C function, e.g. *int, is to translate it to an IN OUT > parameter, but that is arbitrarily not allowed. This isn't the most natural translation, and the prevention of the use of in-out parameters in functions is not arbitrary, it was, as you said earlier, carefully debated. > It is of > course allowed to translate it to an access-to-int parameter, since > there is no restriction on the use of > such parameters for functions, even though they are obviously > logically equivalent from an expressive point of view. They are not logically equivalent. The use of the access parameter implies the (actual) object is aliased (kept in memory essentially all the time). This may be something that C assumes for all its variables (clever compiler deductions notwithstanding), but Ada does not, and rightly so. > The trouble is that although in-out parameters and access-type-to-foo > parameters are equivalent from a logical > point of view, they are very different syntactically, and > we are left with the following unpleasant alternatives in > interfacing to C functions: > > 1. Interface as procedures. This either requires a > wrapper or something like the Valued_Procedure > interface available in GNAT. The trouble with > this is that the calls get really ugly. Yes, in > the case where the result is just an error code > it's acceptable, but that's by no means always > the case. > > 2. Interface using named access types. The calls are > somewhat better here, but you get a plague of aliased > variables appearing, and the access types need > defining which is messy. > > 3. Use a wrapper with global variables for the missing > parameters. But this is nasty anyway, and gets too > far from the C form. To me, it is obvious that option 2 should be used. To describe the required aliasing of variables as a 'plague' is rather an overstatement: it simply means adding the word 'aliased' to the appropriate objects; that's not a plague! It is absolutely right, since they must (at least in effect) be aliased for the called C routine(s) to access them via a pointer. > To me, the arguments for allowing IN OUT parameters, at > least for interfaced functions, are very strong, but > unfortunately, this is an argument that cannot be won. > There seem to be three kinds of people: > > 1. Those who are adamantly opposed to IN OUT parameters > on basically religeous (i.e. belief based) grounds without > very strong technical justification in many cases, or with > the technical justification being inconsistent with the > general permission for functions to have side effects in > Ada. This is a surprisingly large group. Well, as I say above, there is indeed a very strong, very well documented, and generally accepted technical justification for avoiding side-effects in functions (which is the point I was originally making), and disallowing in-out parameters in Ada functions seems to be be perfectly in tune with this principle. > ... To sum up, I am amazed at Robert's opposition to what I have always understood to be a very well established programming principle (in procedural languages such as Ada). That principle is taught for very good software engineering reasons. I said "Must I really repeat these?". If the answer is simply "Yes.", then please just answer "Yes" and I will. -- Nick Roberts