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 05:07:42 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: dewar@gnat.com (Robert Dewar) Newsgroups: comp.lang.ada Subject: Re: Rosen Trick [List container strawman] Date: 4 Nov 2001 05:07:42 -0800 Organization: http://groups.google.com/ Message-ID: <5ee5b646.0111040507.5ca7ea23@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> NNTP-Posting-Host: 205.232.38.14 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1004879262 6280 127.0.0.1 (4 Nov 2001 13:07:42 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 4 Nov 2001 13:07:42 GMT Xref: archiver1.google.com comp.lang.ada:15762 Date: 2001-11-04T13:07:42+00:00 List-Id: "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. Here are the facts: Ada permits functions to have side effects, and does not attempt to prohibit side effects in functions (an odd and inconsistent exception is functions in protected types, and that was indeed a major discussion point in the design) 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. 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. 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. 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 I have never understood the rationale for this inconsistent design. When I talk to someone like Tuck, who basically supports the prohibition, it seems to come from a general feeling that functions should not have side effects. OK, but that's some other language than Ada, where functions are permitted to have side effects. 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. 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. 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, 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. 2. Those who really don't like functions with side effects much, but would tolerate IN OUT parameters if they had to, but are certainly not going to fight for them, and would vote no or abstain. I think I correctly label Tuck and the design team in this second group, which is also fairly large. 3. Those who really find this restriction annoying, and have fought to get it lifted. They are a large group, but somewhat less than a working majority. I don't see anything that would put group 3 in a position to fix this annoying restriction in the near future, so it to me is just a minor defect in the language that will stay uncorrected, but we can live with it, it's not fatal, just very annoying.