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-Thread: a07f3367d7,3867e2f73fa21ec X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,UTF8 X-Received: by 10.66.13.3 with SMTP id d3mr6914093pac.40.1367766553738; Sun, 05 May 2013 08:09:13 -0700 (PDT) Path: ln4ni1432pbb.0!nntp.google.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!goblin1!goblin.stu.neva.ru!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Ada 2012: In-out parameters for functions Date: Sun, 05 May 2013 18:09:11 +0300 Organization: Tidorum Ltd Message-ID: References: <7704abab-86f2-4edc-ad4b-b3d4e70004fb@googlegroups.com> Mime-Version: 1.0 X-Trace: individual.net FNvmxIpRElkaqlc1V38tFA4+WSHVMbBokO+zWgMkLex9vEduYN Cancel-Lock: sha1:ZNpgD3Sx4E2O1XnQMpo1ilIlBD8= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 In-Reply-To: X-Received-Bytes: 5878 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: 2013-05-05T18:09:11+03:00 List-Id: On 13-05-05 15:52 , Bill Findlay wrote: > On 05/05/2013 12:11, in article op.wwlyp5ymule2fv@cardamome, "Yannick > Duchêne (Hibou57)" wrote: > >> Le Sun, 05 May 2013 12:24:50 +0200, Niklas Holsti >> a écrit: >> >>> How about reusing the mode keywords: >>> >>> Proc ( >>> In_Param => in A, >>> Out_Param => out B, >>> In_Out_Param => in out C); >>> >> >>> An alternative, perhaps more English-like, […] >>> >>> Proc ( >>> in In_Param => A, >>> out Out_Param => B, >>> in out In_Out_Param => C); >>> >> >> But may be the first is more Chinese‑like :P (I don't know, I don't know >> Chinese) >> >> Not joking, the first looks better to me, it better express what it means >> as the mode is closer to the actual parameter which is the subject of the >> mode (the same way at the declaration, it is closer to the type, which is >> the best to me for a similar reason). >> >> Seems this topic was not discussed at all for Ada 2012. > > I'm glad to hear it, because the idea is bonkers. "Bonkers" is a bit harsh :-) > Declarations collect relevant info to one easily found place in the code, > instead of having it splattered around at random. The question is if some redundancy in the source code is useful -- Ada users normally reply "yes" -- and what kind and amount of redundancy is useful -- here our opinions can differ. > These suggestions about parameter mode make no more sense than suggesting > that, instead of declaring: > > I : Integer; S ; String; > > One should instead have to write things like: > > I% := I% + 1; > S$ := ""; > > (A la BASIC) ... or a-la type-revealing "Hungarian notation". I hate such redundant declaration of variable types in variable identifiers, so we agree on that kind of redundancy being bonkers (for Ada, at least). Repeating the parameter mode in calls is a different kind of redundancy, with a bit of the flavour of SPARK information-flow analysis. By specifying the modes in the call, the caller is stating a kind of contract, or expectation: "In this call, I expect In_Param not to be modified (even if the actual parameter is a non-constant object), but I do expect that Out_Param will be modified, and that In_Out_Param may be modified." This is problem-domain information (semantics). If the actual modes are different (perhaps through a recent change to the subprogram profile), there is quite likely something wrong, just as if the types of the actuals did not match the formals. Is this redundancy likely to help discover errors, or is it just a nuisance? For Ada, I think Hungarian notation is a nuisance, because Ada programs should use problem-oriented types, which means that a change to the underlying physical type, in the type declaration alone, should be possible without changes to other parts of the source code. Avoiding Hungarian notation works in Ada because of strong typing. In C/C++, where all integer types are implicitly interconvertible, I can see some good in Hungarian notation, since it keeps the type of each variable visible as one writes expressions using that variable, which may help one write expressions that have the intended effect. However, the use of parameter mode notations in Ada calls is not likely to become a nuisance. If the profile of the subprogram being called is changed so that some parameter modes change, it seems to me highly likely that all call sites must at least be inspected to see if they still have the intended effects, and most call sites must probably be modified to take the new parameter modes into account. Without parameter modes in calls, the compiler can point out only some kinds of mode conflicts, such as an uninitialized variable as the actual parameter for an "in" or "in out", or a constant object as the actual parameter for an "out" or "in out". If the calls specify parameter modes, the compiler can point out all mode conflicts. I believe I have made some Ada coding errors that would have been revealed by mode notations in calls. I don't remember the exact examples, but I think one concerned a procedure in which an "in" parameter was changed to an "in out" parameter, because some new uses of the subprogram required it -- but then some old uses no longer worked, because they assumed that the actual for this parameter would not be changed. And the actual was a non-constant object, so the compiler saw nothing wrong in its use for an in-out parameter. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .