Re: Ada 2012: In-out parameters for functions

["Randy Brukardt" <randy@rrsoftware.com>]

"AdaMagica" <christ-usch.grein@t-online.de> 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.