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 18:46:46 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: dewar@gnat.com (Robert Dewar) Newsgroups: comp.lang.ada Subject: Re: Side-Effects in Functions [Rosen Trick] Date: 4 Nov 2001 18:46:46 -0800 Organization: http://groups.google.com/ Message-ID: <5ee5b646.0111041846.93f3e07@posting.google.com> 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> <9s3tl3$111hco$1@ID-25716.news.dfncis.de> NNTP-Posting-Host: 205.232.38.14 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1004928406 16196 127.0.0.1 (5 Nov 2001 02:46:46 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 5 Nov 2001 02:46:46 GMT Xref: archiver1.google.com comp.lang.ada:15782 Date: 2001-11-05T02:46:46+00:00 List-Id: "Nick Roberts" wrote in message news:<9s3tl3$111hco$1@ID-25716.news.dfncis.de>... > 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. No, this is by no means a consensus. Most procedural languages, including Ada, allow functions to have side effects. And on the narrower issue of allowing IN OUT parameters in functions, there is nothing like a consensus opposing this. Indeed my guess is that during the design phase on Ada 95, if a show down had been insisted on, the side favoring IN OUT parameters would have (narrowly) won, but it seemed inappropriate to force this change in the absence of a consensus on the other side. So your understanding of the consensus here is completely wrong. > > 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. Features in Ada are there to be used, anyone who announces that some feature should never be used probably just does not understand the issues. Of course they should not be abused. > 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? Please don't! Many people would say EXACTLY the same about assignments, or global variables. Of course this feature can be misused, as can many features. Forbidding something because it can be misused is an absurd design approach and one that fortunately Ada seldom indulges in. > > 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. Actually the issue of IN OUT parameters was never carefully debated. It was clear early on that it was one of these religeous issues (note Nick's odd use of the phrase "strong belief") which was not something that could be calmly debated (your "good grief" shows this nicely -- why people get so excercised over this issue is a puzzle to me). > 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. Most people feel that being forced to add aliased keywords all over the place, just because of odd interfacing requirements for C functions, is unfortunate. If you find it perfectly fine to have aliased keywords around, fine, but you obviously don't have the alergy to aliasing that many people have. It is not accidental that aliased is not the default. > 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). No wonder if you are amazed if you think this is a "very well established programming principle". That's just wrong. As I noted earlier, nearly all procedural languages DO allow side effects in functions. And of course Ada does too (allow side effects in functions), but has the odd attitude that side effects are only OK if they are not announced in the spec. Consider the following: function f return integer; -- Increments the global variable Q and returns the -- incremented value. function f (Q : in out integer) return integer; -- Increments its argument and returns the incremented -- value. I find it odd that Ada allows the first and disallows the second, and many others would agree with me. Nick, no one will try to convince you that you are wrong here, because it is a waste of time, but you should learn that you are quite wrong if you think your viewpoint somehow represents a general consensus. I and many other experts in programming languages in general, and Ada in particular, disagree with you. The fact is there is no consensus on either side of this issue. Oddly, the feeling that goto statements should never be used has much *stronger* support than the feeling that IN OUT parameters should not be allowed in functions, yet Ada does permit goto statements. I think the actual situation is that this is one of these cases where the designers get to decide, since there is no consensus. JDI accepted gotos, but felt that functions should have no side effects whatever. That was untenable, and he was argued out of this extreme position, with the result that we ended up with a rather odd compromise. Tuck is also somewhat (though not fanatically like you) opposed to IN OUT parameters for functions, so was not about to decree that they should go in. > That principle is taught for very good > software engineering reasons. I said "Must I really > repeat these?". If you have been taught that functions should never ever have side effects, you have been taught by a fanatic. Such fanaticism is almost never helpful.