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,ASCII-7-bit X-Received: by 10.180.182.6 with SMTP id ea6mr529045wic.4.1367625258792; Fri, 03 May 2013 16:54:18 -0700 (PDT) MIME-Version: 1.0 Path: p18ni64704wiv.0!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!193.141.40.65.MISMATCH!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.fsmpi.rwth-aachen.de!reality.xs3.de!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Ada 2012: In-out parameters for functions Date: Fri, 3 May 2013 18:54:14 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <7704abab-86f2-4edc-ad4b-b3d4e70004fb@googlegroups.com> <7446fa12-42ce-4716-b0ef-e7eab9005fdb@googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1367625258 20973 69.95.181.76 (3 May 2013 23:54:18 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 3 May 2013 23:54:18 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2013-05-03T18:54:14-05:00 List-Id: "AdaMagica" wrote in message news:7446fa12-42ce-4716-b0ef-e7eab9005fdb@googlegroups.com... > Again some misinformation from anon. > > On Friday, May 3, 2013 12:48:29 PM UTC+2, anon wrote: ... >> Another change is the "Copy by Reference" has been replaced by >> "Copy by Type". This change alone defeats the purpose of the >> "limited private" used in Generics compilation units aka external >> re-usable libraries which forces existing libraries to be >> re-written. So, many companies that used Generic libraries are >> now leaving Ada for a language that does not alter a major language >> feature after 25 plus years of the language existence. > > I guess return-by-reference vs. build-in-place is meant here. > That was a change from Ada 95 to Ada 2005. > ARG felt that return-by-reference was a big mistake, so they corrected it. > Ada83 functions returning tasks were a big problem. Not to mention that it was an Ada 95 invention. There's nothing quite like in in Ada 83. So you could equally complain about it's introduction. It is true, however, that the elimination of return-by-reference (a truely useless idea in my experience) has caused some companies to stick with Ada 95. It took heroic work-arounds to make return-by-reference useful for anything, but if you put one of those workarounds into your system, it's equally hard to get it out. (Claw in fact has one of those for the predefined registry keys, Ada 2005 requires a rather different package body -- not a huge deal but a definite annoyance.) ... >> And both functions with "in out" parameters and "conditional >> statements" can cause erroneous coding which leads to erroneous >> executions. LoL. I'm imagining the group of people protesting against the inclusion of "if statements" in Ada 83, because it can cause "erroneous coding". And I'm trying to imagine a programming language without "conditional statements" -- a purely functional language doesn't have "statements", so it might qualify, but then of course it would have "conditional expressions" instead. I suppose "anon" really meant "conditional expressions", but how those can "cause erroneous coding" is beyond me. The parts of a conditional expression are subject to the same rules as any other Ada expression, including type checking, accessibility checking, and all of the legality rules. It's just a more convinient way to write an if or case statement (with the added benefit of potentially being a static expression). Indeed, Janus/Ada turns most if and case *statements* into *expressions* for optimization purposes. This is a semantics-preserving transformation (in both directions), so it's hard to imagine why "if statements" are OK and "if expressions" are not. ... > You may like or dislike these features, but they do not introduce side > effects > into functions, they only make the previous hidden ways obvious. The problem with "in out" parameters (for *any* subprogram) is at the call site, not in the declaration. And that problem stems from the fact that Ada does not require an order of evaluation in expressions (including calls). That very bad decision will always make Ada less safe (any version of Ada, going back to Ada 83) than a language that requires a specific order. It's easy to write expressions in Ada 95 that depend on the order of evaluation, and you'll never find out until you use a different compiler or optimization setting. Ada 2012 at least tries to mitigate this problem by making obvious cases of order dependency illegal. But it cannot fix the root problem -- which in out parameters for functions just makes a bit more visible. (And of course, nothing requires any user of Ada 2012 to use a "in out" parameter to a function nor a conditional expression. Put it into your style guide to avoid them if you like - and if you don't have an enforced style guide, you've got much larger [management] problems than anything a new language version could dish out. The ARG does not send people to every Ada programmer's place of business demanding that programmers use "in out" parameters, conditional expressions, and aspect specifications instead of those old obsolete if statements and pragmas! :-) Randy.