Re: Ada 2012: In-out parameters for functions

[AdaMagica <christ-usch.grein@t-online.de>]

Again some misinformation from anon.

On Friday, May 3, 2013 12:48:29 PM UTC+2, anon wrote:
> For Ada 83 functions the DOD required a language that contains a 
> true function and not the C like function. But since 1998 when the 
> DOD drop the Ada requirement, the Ada maintainers were allowed to 
> alter the definition of a function.

http://archive.adaic.com/docs/reports/steelman/steelman.htm#7
There is no such requirement in Steelman.

Ada functions have always had parameters of access types, which allow a kind of out-parameters.
They also have been able to modify global parameters, a hidden form of out-parameters.
Thus they always have been able to have side effects, albeit were not allowed to say so.

> Since then one or more of Ada maintainers have decided to add number 
> of "C" like syntax and/or coding to Ada. An example is the "conditional 
> statements" another is the the "C" function/procedure call with both 
> having in out parameters.  A number of old "C" compilers ( 1980..1990s 
> from Microsoft and IBM ) allowed the "in out" parameters for C 
> functions.
>
> 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.

> Also, Robert Dewar the CEO at Adacore and the main maintainer at the
> movement for Ada stated that they would modify Ada to help increase
> the number of Ada programmers.  Robert Dewar as CEO has to look at 
> Adacore profits and not just designs a better language which means 
> that Ada may suffer due to Adacore's profitability.  But what most 
> programmers want is the best language with the best features that 
> are not features that can lead to erroneous error in coding or 
> execution.

No comment on AdaCore bashing...

> And both functions with "in out" parameters and "conditional 
> statements" can cause erroneous coding which leads to erroneous 
> executions. And for that reason these features should have never 
> been added to Ada.
>
> This means Ada has stated going down the path of previous languages 
> like PL/1, C, Lisp and even Java. So, programmers are looking for 
> the next language that maintainers will not just adopt the bad designs 
> from previous language maintainers.

You may like or dislike these features, but they do not introduce side effects into functions, they only make the previous hidden ways obvious.