Ada 2012: In-out parameters for functions

Ada 2012: In-out parameters for functions

[dptrash]

Why does Ada 2012 have in-out parameters for functions?

Quote from the book 'Ada 2005 Rationale' (page 4): "[..] Indeed many other changes were rejected as really unnecessary. These include old chestnuts such as in out and out parameters for functions (ugh), [..]".

So, when do I use functions or procedures. Functions have return values. Any other differences?

- Dennis

Re: Ada 2012: In-out parameters for functions

[Shark8]

On Wednesday, May 1, 2013 10:28:07 AM UTC-6, dpt...@arcor.de wrote:
> 
> So, when do I use functions or procedures. Functions have return values. Any other differences?

Not really. Though a function w/ out parameters could be used like this:

-- Given Recognize(P : Pattern, S : String, O : out Object_Type) Return Boolean

if Recognize( Pattern_1, Input, Object ) then
 -- process object
elsif Recognize( Pattern_2, Input, Object ) then
 -- process object
end if;

Another thing is that functions can output unconstrained types [but the result is constrained], which means they can be used to assign to arrays or tagged-type 'CLASSes or the or discriminated types.

So we could now have a tokenizer like this:

-- Token_List: Vector containing the type Token.

Function Tokenize(Input : String) Return Token_List is
   -- Nested Tokenize consumes a portion of the string and returns a token.
   Function Tokenize(Input : in out Unbounded_String) Return Token
    with pre => Length(Unbounded_String) > 0;
   [...]
    Working : Unbounded_String:= To_Unbounded_String( Input );
begin
   Return Result : Token_List do
    while Length(Working) > 0 loop
      Result.Append( Tokenize(Working) );
    end loop;
   End return;
end Tokenize;

Re: Ada 2012: In-out parameters for functions

[Yannick Duchêne (Hibou57)]

Le Wed, 01 May 2013 18:28:07 +0200, <dptrash@arcor.de> a écrit:

> Why does Ada 2012 have in-out parameters for functions?
>
> Quote from the book 'Ada 2005 Rationale' (page 4): "[..] Indeed many  
> other changes were rejected as really unnecessary. These include old  
> chestnuts such as in out and out parameters for functions (ugh), [..]".
>
> So, when do I use functions or procedures. Functions have return values.  
> Any other differences?
>
> - Dennis

This is just personal opinion, I don't speak for anyone else:

I did not enjoy neither the out mode parameters for functions in Ada 2012,  
but after some though, had the conviction it's not that much bad.

On one hand, you were already able to have functions with side effects  
prior to Ada 2012, which is even worse than out parameters. If a function  
modifies an outer level variable which is visible from its body, and that  
variable may be interpreted later from outside of the body of this  
function, that's less clear than using an out parameter.

Then, there is what a function do and how it is implemented. Out mode  
parameters is just implementation after‑all, and sometime, you may really  
need out parameters to complete the purpose of a rally pure function: Ada  
function does not returns tuples like SML's functions may do, and to  
achieve this in Ada, you need out parameters, or else you may have to  
define multiple types everywhere (if all elements of the tuples have  
different types, you do not really need to define a record type for that,  
as there is no way to take one element for another).

Semantic is one thing, implementation is another. And if you want  
functional programming in Ada, you need out parameters.

In/out (both way) parameters may be another story, and may more suggest  
this is a procedure and not a function, but still the same: semantic is  
one thing, implementation is another, and there is not always an exact  
match of one on the other.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada 2012: In-out parameters for functions

[Dmitry A. Kazakov]

On Wed, 01 May 2013 21:04:03 +0200, Yannick Duch�ne (Hibou57) wrote:

> In/out (both way) parameters may be another story, and may more suggest  
> this is a procedure and not a function,

function Read (Stream : in out Root_Stream_Type) return String;

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada 2012: In-out parameters for functions

[Yannick Duchêne (Hibou57)]

Le Wed, 01 May 2013 21:37:43 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:

> On Wed, 01 May 2013 21:04:03 +0200, Yannick Duchêne (Hibou57) wrote:
>
>> In/out (both way) parameters may be another story, and may more suggest
>> this is a procedure and not a function,
>
> function Read (Stream : in out Root_Stream_Type) return String;
>

:D

This is more a procedure than a function (it either won't return the same  
the next time invoked with the same argument or either the argument can  
never be considered to be the same as it use to be any‑more), and a  
function construct is used only because it is preferable to return an  
unconstrained type (as Shark8 mentionned) than an access to the same  
object allocated on the heap and returned via an out mode access type  
parameter of a procedure.

That's a good example of how a construct may not always match the intended  
semantic; it may happens one use a function to implement a procedure, or a  
procedure to implement a function.

I feel `function` and `procedure` in Ada means something at the  
implementation level more than at the intention level, even if many times  
both matches as gloves and hands.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada 2012: In-out parameters for functions

[Dmitry A. Kazakov]

On Wed, 01 May 2013 21:58:36 +0200, Yannick Duchêne (Hibou57) wrote:

> Le Wed, 01 May 2013 21:37:43 +0200, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a écrit:
> 
>> On Wed, 01 May 2013 21:04:03 +0200, Yannick Duchêne (Hibou57) wrote:
>>
>>> In/out (both way) parameters may be another story, and may more suggest
>>> this is a procedure and not a function,
>>
>> function Read (Stream : in out Root_Stream_Type) return String;
> 
> :D
> 
> This is more a procedure than a function (it either won't return the same  
> the next time invoked with the same argument or either the argument can  
> never be considered to be the same as it use to be any‑more),

Surely it will. Same argument means same value and the value of a stream is
its state. If the stream is in the same state the function will return same
result.

> and a  
> function construct is used only because it is preferable to return an  
> unconstrained type

Not only. Functions are used when there is a dedicated result/effect which
is used as an input for another routine or language construct.

> That's a good example of how a construct may not always match the intended  
> semantic;

The semantics [in the context of program design] of a function and
procedure are exactly same, it is called "subroutine."

> I feel `function` and `procedure` in Ada means something at the  
> implementation level more than at the intention level, even if many times  
> both matches as gloves and hands.

Ada 83 confused function as a syntactic form of a subroutine with pure
function. Allowing in/out arguments resolves that only partially. Pure
functions (of different purity levels) are still needed.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada 2012: In-out parameters for functions

[Yannick Duchêne (Hibou57)]

Le Thu, 02 May 2013 08:41:41 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
>> This is more a procedure than a function (it either won't return the  
>> same
>> the next time invoked with the same argument or either the argument can
>> never be considered to be the same as it use to be any‑more),
>
> Surely it will. Same argument means same value and the value of a stream  
> is
> its state. If the stream is in the same state the function will return  
> same
> result.

If the state includes the last operation time (with non‑overlapping time  
guaranteed for each operations), then that may be an example where it  
could make sense.

>> and a
>> function construct is used only because it is preferable to return an
>> unconstrained type
>
> Not only. Functions are used when there is a dedicated result/effect  
> which
> is used as an input for another routine or language construct.

Yes, that's the only way to expressions.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada 2012: In-out parameters for functions

[Peter C. Chapin]

On 05/01/2013 12:28 PM, dptrash@arcor.de wrote:

> Why does Ada 2012 have in-out parameters for functions?
>
> Quote from the book 'Ada 2005 Rationale' (page 4): "[..] Indeed many other changes were rejected as really unnecessary. These include old chestnuts such as in out and out parameters for functions (ugh), [..]".

Section 4.2 of the Ada 2012 Rationale addresses this question. One 
particularly interesting sentence is: "The big concern was that allowing 
parameters of all modes might open the door to dangerous programming 
practices but a solution to that was found in the introduction of 
stricter rules preventing many order dependences."

Even in Ada 2005 it was permitted to pass access types to functions, 
effectively allowing a function to modify its parameter (via the access 
value). So in that respect not much has changed except that access types 
are no longer needed in yet another place in Ada.

Peter

Re: Ada 2012: In-out parameters for functions

[anon]

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.

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.

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. 

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.



dptrash@arcor.de wrote in
news:7704abab-86f2-4edc-ad4b-b3d4e70004fb@googlegroups.com: 

> Why does Ada 2012 have in-out parameters for functions?
> 
> Quote from the book 'Ada 2005 Rationale' (page 4): "[..] Indeed many
> other changes were rejected as really unnecessary. These include old
> chestnuts such as in out and out parameters for functions (ugh),
> [..]". 
> 
> So, when do I use functions or procedures. Functions have return
> values. Any other differences? 
> 
> - Dennis
> 

Re: Ada 2012: In-out parameters for functions

[Simon Clubley]

On 2013-05-03, anon <anon@anon.org> wrote:
> 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.
>

What languages are these companies moving to and how do those languages
compare safety wise with Ada ?

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: Ada 2012: In-out parameters for functions

[Simon Wright]

anon <anon@anon.org> writes:

> 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 don't think I've ever used a limited private formal type, and I don't
recognise 'has to be rewritten'.

So, which generic libraries are you thinking of? And which companies are
these?

Re: Ada 2012: In-out parameters for functions

[Yannick Duchêne (Hibou57)]

Le Fri, 03 May 2013 12:48:29 +0200, anon <anon@anon.org> a écrit:
> 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"

That's not that much specifically C‑like. You have the same in formal  
languages like SML where everything is an expression. That's not typical  
of C, and that's not this feature which makes C unusable as soon beyond  
the tiny scale.

> 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.

You could already have less safe hidden side effects, and as some one  
mentioned, you could modify an argument via some indirection. In/out makes  
clear what was hidden, which is finally safer (Ada is a procedural  
language, not a pure functional language). However, I personally still  
miss the ability to remind in/in‑out/out modes at the call‑place, and  
that's the main grief I have with Ada on that topic.

> Another change is the "Copy by Reference" has been replaced by
> "Copy by Type".

What is “copy by type”?

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada 2012: In-out parameters for functions

[Yannick Duchêne (Hibou57)]

Le Fri, 03 May 2013 13:42:02 +0200, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
> However, I personally still miss the ability to remind in/in‑out/out  
> modes at the call‑place, and that's the main grief I have with Ada on  
> that topic.

While there is a syntactical tip to get part of this, with the argument  
surrounded in parentheses:


     function Plus_Plus_Ada
       (E : in out Integer)
        return Integer;
     -- Don't laugh, that's not `Ada_Plus_Plus` :D

     function Plus_Plus_Ada
       (E : in out Integer)
       return Integer is
     begin
        E := E + 1;
        return E;
     end;

     -- … Two sample use‑cases

     -- This will pass compilation:

     declare
        I : Integer := 0;
     begin
        I := Plus_Plus_Ada (I);
     end;

     -- This will not pass compilation,
     -- and will give you an error about
     -- `I` which must be a variable:

     declare
        I : Integer := 0;
     begin
        I := Plus_Plus_Ada ((I));
     end;


But that's a bit like the `non null` for access type, which should have  
been the default. Would be better if to have to explicitly says you know  
the argument may be modified, instead of explicitly say you expect it to  
not be modified and add parentheses everywhere.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada 2012: In-out parameters for functions

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1822 bytes --]

"Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> wrote in message 
news:op.wwibdpw7ule2fv@cardamome...
...
>But that's a bit like the `non null` for access type, which should have 
>been the default. Would be better if to have to explicitly says you know 
>the argument may be modified, instead of explicitly say you expect it to 
>not be modified and add parentheses everywhere.

Right, but of course Ada gets this wrong from the very beginning. "constant" 
should be the default (everywhere), and you ought to have to declare 
variables. Something like:

     A : variable Integer;
     Len : Integer := 10;
     Len2 : constant Integer := 10; -- Same as the previous.

That's how parameters work, after all.

I agree that named notation should include the direction of the parameter, 
but again its way too late to fix. The best syntax would have been
     Proc (In_Param => A, Out_Param <= B, In_Out_Param <=> C);
but unfortunately "<=" is used for less-than-or-equals and trying to use it 
in this context would be ambiguous.

So the best practical syntax would be:
     Proc (In_Param -> A, Out_Param <- B, In_Out_Param <-> C);

But adding new compound delimiters has never been done (lexical elements are 
unchanged since Ada 83, the only changes being to allow Unicode characters 
in identifiers and strings), and this scares people. Moreover, we don't have 
any current delimiters that have three characters. So this would likely have 
a lot of change to tools, at a very fundemental level.

I suppose if I was designing a new Ada-like language, this is one of the 
things I would do. (Along with overloading for objects and exceptions, 
replacing untagged derived types with some sort of type renaming, and a 
reduction in little used features).

                                              Randy.

Re: Ada 2012: In-out parameters for functions

[Adam Beneschan]

On Friday, May 3, 2013 4:29:46 PM UTC-7, Randy Brukardt wrote:

> I agree that named notation should include the direction of the parameter, 
> but again its way too late to fix. The best syntax would have been
>      Proc (In_Param => A, Out_Param <= B, In_Out_Param <=> C);
> but unfortunately "<=" is used for less-than-or-equals and trying to use it 
> in this context would be ambiguous.
> 
> So the best practical syntax would be:
>      Proc (In_Param -> A, Out_Param <- B, In_Out_Param <-> C);
> But adding new compound delimiters has never been done (lexical elements are 
> unchanged since Ada 83, the only changes being to allow Unicode characters 
> in identifiers and strings), and this scares people. Moreover, we don't have 
> any current delimiters that have three characters. So this would likely have 
> a lot of change to tools, at a very fundemental level.

This particular change would break any code that looks like

      if X<-1 then ...

and you just gotta know that there's some out there, no matter how ugly it looks. 

Ada 80 (?) would have said

    Proc (In_Param =: A, Out_Param := B, In_Out_Param :=: C)

Don't know why they didn't stick with it.

                                   -- Adam

Re: Ada 2012: In-out parameters for functions

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:885a6f9e-cb8b-4823-9f02-3cab5f172076@googlegroups.com...
...
>> Ada 80 (?) would have said
>>
>>    Proc (In_Param =: A, Out_Param := B, In_Out_Param :=: C)

I think that was Ada 79. We started implementing Ada 80 (it was 1981, after 
all, Ada 83 was still a couple years away), and it didn't have those 
symbols. I just pulled the our (last) Ada 80 manual off the shelf, and it 
has the same list of delimiters that Ada 2012 does.

> Don't know why they didn't stick with it.

That I don't know, it predates me as noted above. It's ugly?? :-)

                                      Randy.

Re: Ada 2012: In-out parameters for functions

[Niklas Holsti]

On 13-05-04 02:29 , Randy Brukardt wrote:

> I agree that named notation should include the direction of the parameter, 
> but again its way too late to fix. The best syntax would have been
>      Proc (In_Param => A, Out_Param <= B, In_Out_Param <=> C);
> but unfortunately "<=" is used for less-than-or-equals and trying to use it 
> in this context would be ambiguous.
> 
> So the best practical syntax would be:
>      Proc (In_Param -> A, Out_Param <- B, In_Out_Param <-> C);

How about reusing the mode keywords:

   Proc (
      In_Param  => in A,
      Out_Param => out B,
      In_Out_Param => in out C);

The mode keywords would be optional, of course, thus this extension
would be upwards compatible with current Ada. Note that this syntax can
be used with positional association calls, too:

   Proc (in A, out B, in out C);

An alternative, perhaps more English-like, would be to put the mode
keywords in front of the formal parameter:

   Proc (
      in In_Param  => A,
      out Out_Param => B,
      in out In_Out_Param => C);

but I like the first form better, because its form and format are more
familiar, especially when the "=>" are vertically aligned.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Ada 2012: In-out parameters for functions

[Yannick Duchêne (Hibou57)]

Le Sun, 05 May 2013 12:24:50 +0200, Niklas Holsti  
<niklas.holsti@tidorum.invalid> 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.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada 2012: In-out parameters for functions

[Bill Findlay]

On 05/05/2013 12:11, in article op.wwlyp5ymule2fv@cardamome, "Yannick
Duchêne   (Hibou57)" <yannick_duchene@yahoo.fr> wrote:

> Le Sun, 05 May 2013 12:24:50 +0200, Niklas Holsti
> <niklas.holsti@tidorum.invalid> 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.

Declarations collect relevant info to one easily found place in the code,
instead of having it splattered around at random.

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)

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: Ada 2012: In-out parameters for functions

[Niklas Holsti]

On 13-05-05 15:52 , Bill Findlay wrote:
> On 05/05/2013 12:11, in article op.wwlyp5ymule2fv@cardamome, "Yannick
> Duchêne   (Hibou57)" <yannick_duchene@yahoo.fr> wrote:
> 
>> Le Sun, 05 May 2013 12:24:50 +0200, Niklas Holsti
>> <niklas.holsti@tidorum.invalid> 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
      .      @       .

Re: Ada 2012: In-out parameters for functions

[Yannick Duchêne (Hibou57)]

Le Sun, 05 May 2013 17:09:11 +0200, Niklas Holsti  
<niklas.holsti@tidorum.invalid> a écrit:
> 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.

That's an argument for Randy's idea to make constant the default mode for  
local variable and constant declarations.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada 2012: In-out parameters for functions

[Niklas Holsti]

On 13-05-05 22:23 , Yannick Duchêne (Hibou57) wrote:
> Le Sun, 05 May 2013 17:09:11 +0200, Niklas Holsti
> <niklas.holsti@tidorum.invalid> a écrit:
>> 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.
> 
> That's an argument for Randy's idea to make constant the default mode
> for local variable and constant declarations.

Perhaps... as I remember, this object (the actual parameter in the
example I remember) was an array, or a record, which was built up by
several assignment statements, so it could not be a constant, without
considerable changes to the code.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Ada 2012: In-out parameters for functions

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:aunb0nFir95U1@mid.individual.net...
...
> 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.

Right. But the flip side to this is that it would be impossible to 
compatibly change a subprogram specification. Today, we can change "in out" 
to "in" and "in out" to "out" without breaking any calls -- and I've had to 
do both. Having the modes everywhere would definitely make the code more 
fragile.

OTOH, there clearly are cases where having the mode explicitly mentioned 
would help readability (i.e. "in out" in functions).

I don't think it is clear-cut either way. But I would like to see some nice 
syntax, none of which seems possible for Ada.

                                           Randy.

Re: Ada 2012: In-out parameters for functions

[Yannick Duchêne (Hibou57)]

Le Tue, 07 May 2013 02:30:47 +0200, Randy Brukardt <randy@rrsoftware.com>  
a écrit:
> Right. But the flip side to this is that it would be impossible to
> compatibly change a subprogram specification. Today, we can change "in  
> out"
> to "in" and "in out" to "out" without breaking any calls -- and I've had  
> to
> do both. Having the modes everywhere would definitely make the code more
> fragile.

That would be at author's discretion, would not be required.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada 2012: In-out parameters for functions

[Yannick Duchêne (Hibou57)]

Le Sun, 05 May 2013 14:52:18 +0200, Bill Findlay  
<yaldnif.w@blueyonder.co.uk> a écrit:
>> Seems this topic was not discussed at all for Ada 2012.
>
> I'm glad to hear it, because the idea is bonkers.
>
> Declarations collect relevant info to one easily found place in the code,
> instead of having it splattered around at random.
>
> 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)

Rational for Ada 2022 says:
> We wanted to help the users to tracks variable dependencies
> and side effects on variables. The declaration and thus the
> type of a variables is typically not very far and most of
> times, local (or when not that close, that's typically a
> constant defined in a specification, and a constant is less
> cause of errors than a variable). Function declarations are
> on the opposite, typically far away and not local, so it's
> easier to lose track of sub‑program signatures than lose track
> of variable types. Thus, Ada 2022 added some syntax to allow
> users to express there intended effects in a way which allow the
> compiler to catch any erroneous assumptions.

I fully agree with the Rational for Ada 2022.

Then, there is nothing bad in helping catching errors and unintended  
behaviours.

Personally my option for a syntax would be something like with SML (SML  
being the de‑facto standard to me, at avoiding unwanted side‑effects):


     -- Declaration:

     procedure P
       (A, B :    out The_Type;
        C, D : in out The_Type;
        E, F : in     The_Type);

     -- Use case:

     (A, B, C, D) := P (C, D, E, F);


What appears on the LHS would be what's “out” or “in out” and what appears  
on the RHS would be what's “in” or “in out”, with what's “in out”  
appearing both on the LHS and RHS.

But I have no hope for it to be ever accepted, as the call‑place syntax  
would surely be too much far from typical Ada syntax, and may be too few  
people are used to this kind of syntax.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada 2012: In-out parameters for functions

[Adam Beneschan]

On Sunday, May 5, 2013 5:52:18 AM UTC-7, Bill Findlay wrote:
> On 05/05/2013 12:11, in article op.wwlyp5ymule2fv@cardamome, "Yannick

> >> How about reusing the mode keywords:
> 
> >>    Proc (
> >>       In_Param  => in A,
> >>       Out_Param => out B,
> >>       In_Out_Param => in out C);

>> Seems this topic was not discussed at all for Ada 2012.

> I'm glad to hear it, because the idea is bonkers.
> 
> Declarations collect relevant info to one easily found place in the code,
> instead of having it splattered around at random.

No, I don't think you understand.  This isn't a declaration.  The place where you tell the compiler what the parameter mode is would be the same place where it's always been, when the called subprogram is declared.  Allowing mode declarations in the call would serve two purposes: (1) to alert someone reading the program to the fact that the function call may change one of its parameters, and (2) as a check.  I could envision someone writing

   if Some_Function (Param => in X) then ...

because they're assuming the function call won't change X.  But if it turns out they've made a mistake, or if (due to overloading) the function actually called is a different one from what the programmer thought, or if another programmer unknowingly changes the declaration of Some_Function later, then the compiler would catch the error.  Adding a parameter mode in a call could *not* change the meaning of a program; the effect would be exactly the same if it doesn't cause the compiler to reject the program.

I actually think #1 is more important, because I can attest to the fact that a function call that changes its parameter can make code really difficult to read.  Pascal allows this, and I can't count the number of times I've misunderstood what Pascal code does because I see a function call with a variable parameter that looks like it's just testing the value, when in reality it's changing the variable.  This is partly due to poor naming choices by other programmers, to be sure.  But I believe it would be very valuable for a programmer to be able to put something in the code to help clarify their intentions.  (And it's harder to do this with a comment in Ada than in Pascal, since Pascal has in-line comments.)

                             -- Adam

Re: Ada 2012: In-out parameters for functions

[Bill Findlay]

On 06/05/2013 16:40, in article
19a6badd-ed0f-4023-9100-b9ab653a7f23@googlegroups.com, "Adam Beneschan"
<adam@irvine.com> wrote:

> On Sunday, May 5, 2013 5:52:18 AM UTC-7, Bill Findlay wrote:
>> On 05/05/2013 12:11, in article op.wwlyp5ymule2fv@cardamome, "Yannick
> 
>>>> How about reusing the mode keywords:
>> 
>>>>    Proc (
>>>>       In_Param  => in A,
>>>>       Out_Param => out B,
>>>>       In_Out_Param => in out C);
> 
>>> Seems this topic was not discussed at all for Ada 2012.
> 
>> I'm glad to hear it, because the idea is bonkers.
>> 
>> Declarations collect relevant info to one easily found place in the code,
>> instead of having it splattered around at random.
> 
> No, I don't think you understand.

Oh, I think I do understand.

> This isn't a declaration.
  ^^^^^^^^^^^^^^^^^^^^^^^^
...

> The place where you tell the compiler what the parameter mode is
> would be the same place where it's always been,
> when the called subprogram is declared.

> Allowing mode declarations in the call would serve two purposes:
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You seem to be somewhat inconsistent here.

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: Ada 2012: In-out parameters for functions

[Adam Beneschan]

On Monday, May 6, 2013 9:17:52 AM UTC-7, Bill Findlay wrote:

> 
> Oh, I think I do understand.
> 
> > This isn't a declaration.
> 
>   ^^^^^^^^^^^^^^^^^^^^^^^^
> 
> ...

> > Allowing mode declarations in the call would serve two purposes:
> 
>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> You seem to be somewhat inconsistent here.

No, just suffering from caffeine deficiency syndrome.  Of course I didn't mean "declarations" in the last case.  Change this to "mode specifications", or "mode keywords", or something like that.  I just typed the wrong word.  

    Allowing mode keywords in the call would serve two purposes: [etc...]

It does not declare the parameter mode.

                             -- Adam

Re: Ada 2012: In-out parameters for functions

[Bill Findlay]

On 06/05/2013 17:47, in article
7d34787f-9965-42bc-b847-6ccbbf473f6a@googlegroups.com, "Adam Beneschan"
<adam@irvine.com> wrote:

> On Monday, May 6, 2013 9:17:52 AM UTC-7, Bill Findlay wrote:
> 
>> 
>> Oh, I think I do understand.
>> 
>>> This isn't a declaration.
>> 
>>   ^^^^^^^^^^^^^^^^^^^^^^^^
>> 
>> ...
> 
>>> Allowing mode declarations in the call would serve two purposes:
>> 
>>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 
>> You seem to be somewhat inconsistent here.
> 
> No, just suffering from caffeine deficiency syndrome.

I know the feeling. 8-)

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: Ada 2012: In-out parameters for functions

[Dennis Lee Bieber]

On Mon, 6 May 2013 09:47:34 -0700 (PDT), Adam Beneschan
<adam@irvine.com> declaimed the following in comp.lang.ada:

> No, just suffering from caffeine deficiency syndrome.  Of course I didn't mean "declarations" in the last case.  Change this to "mode specifications", or "mode keywords", or something like that.  I just typed the wrong word.  
> 
>     Allowing mode keywords in the call would serve two purposes: [etc...]
> 
> It does not declare the parameter mode.
>
	While I don't care for the proposal -- don't we have an IDE lying
around that could look up the declaration while cursoring over a call?
I'd suggest replacing "mode keywords" with "intent keywords"
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: Ada 2012: In-out parameters for functions

[Yannick Duchêne (Hibou57)]

Le Tue, 07 May 2013 02:07:21 +0200, Dennis Lee Bieber  
<wlfraed@ix.netcom.com> a écrit:
> 	While I don't care for the proposal -- don't we have an IDE lying
> around that could look up the declaration while cursoring over a call?
> I'd suggest replacing "mode keywords" with "intent keywords"

Ada source, whatever their format is (actually plain text), should be  
readable without the help of analysis of an IDE's tools, I personally  
expect it to be readable as text in whatever format, readable in the  
format it is to be written with. Else that would mean Ada RM should also  
specifies IDE's required capabilities? The analysis tools are for the  
added value, not the primary value, and should not be required to read the  
source correctly (just a personal expectation though, opinions may  
differs).

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada 2012: In-out parameters for functions

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1563 bytes --]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> wrote in message 
news:op.wwlyp5ymule2fv@cardamome...
>Le Sun, 05 May 2013 12:24:50 +0200, Niklas Holsti 
><niklas.holsti@tidorum.invalid> 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.

Not at all true. It was considered as part of AI05-0144-1, the AI that added 
the order-of-evaluation legality checks to the language. We decided to do 
nothing because there was no agreement on what syntax to use (as noted in 
this thread) and there also was a minority of people who thought it was a 
bad idea (also noted in this thread).

It's true that it didn't get a separate AI, but it was included in the AI 
dealing with the problem of function calls with side-effects -- which is the 
only important reason to consider it. We create AIs for *problems*, not for 
*solutions*.

                               Randy.

Re: Ada 2012: In-out parameters for functions

[Adam Beneschan]

On Sunday, May 5, 2013 3:24:50 AM UTC-7, Niklas Holsti wrote:
> On 13-05-04 02:29 , Randy Brukardt wrote:
> 

> How about reusing the mode keywords:
> 
>    Proc (
>       In_Param  => in A,
>       Out_Param => out B,
>       In_Out_Param => in out C);
> 
> The mode keywords would be optional, of course, thus this extension
> would be upwards compatible with current Ada. Note that this syntax can
> be used with positional association calls, too:
> 
>    Proc (in A, out B, in out C);
> 
> An alternative, perhaps more English-like, would be to put the mode
> keywords in front of the formal parameter:
> 
>    Proc (
>       in In_Param  => A,
>       out Out_Param => B,
>       in out In_Out_Param => C);
> 
> but I like the first form better, because its form and format are more
> familiar, especially when the "=>" are vertically aligned.

I checked my archive of Ada-Comment mail, and it seems we had this exact discussion around March 2009.  It looks like I suggested one of the syntaxes you mentioned, and the people who commented afterward seemed to be split about evenly between those who like the idea and those who hated it.  (You contributed a comment too, on the "like" side.)  It doesn't look like this was ever turned into an AI or an AC, though; at least, I can't find it.  Bob Duff was the one who pointed out how Ada 79 handled it.

                          -- Adam

Re: Ada 2012: In-out parameters for functions

[Randy Brukardt]

As mentioned earlier, this is included in AI05-0144-1; you'll find that 
older thread in the appendix of that AI.

                         Randy.

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:42ab7a8e-78ec-4b41-bdca-3f785cc5d5ef@googlegroups.com...
On Sunday, May 5, 2013 3:24:50 AM UTC-7, Niklas Holsti wrote:
> On 13-05-04 02:29 , Randy Brukardt wrote:
>

> How about reusing the mode keywords:
>
>    Proc (
>       In_Param  => in A,
>       Out_Param => out B,
>       In_Out_Param => in out C);
>
> The mode keywords would be optional, of course, thus this extension
> would be upwards compatible with current Ada. Note that this syntax can
> be used with positional association calls, too:
>
>    Proc (in A, out B, in out C);
>
> An alternative, perhaps more English-like, would be to put the mode
> keywords in front of the formal parameter:
>
>    Proc (
>       in In_Param  => A,
>       out Out_Param => B,
>       in out In_Out_Param => C);
>
> but I like the first form better, because its form and format are more
> familiar, especially when the "=>" are vertically aligned.

I checked my archive of Ada-Comment mail, and it seems we had this exact 
discussion around March 2009.  It looks like I suggested one of the syntaxes 
you mentioned, and the people who commented afterward seemed to be split 
about evenly between those who like the idea and those who hated it.  (You 
contributed a comment too, on the "like" side.)  It doesn't look like this 
was ever turned into an AI or an AC, though; at least, I can't find it.  Bob 
Duff was the one who pointed out how Ada 79 handled it.

                          -- Adam 

Re: Ada 2012: In-out parameters for functions

[Yannick Duchêne (Hibou57)]

Le Sun, 05 May 2013 12:24:50 +0200, Niklas Holsti  
<niklas.holsti@tidorum.invalid> a écrit:

> On 13-05-04 02:29 , Randy Brukardt wrote:
>
>> I agree that named notation should include the direction of the  
>> parameter,
>> but again its way too late to fix. The best syntax would have been
>>      Proc (In_Param => A, Out_Param <= B, In_Out_Param <=> C);
>> but unfortunately "<=" is used for less-than-or-equals and trying to  
>> use it
>> in this context would be ambiguous.
>>
>> So the best practical syntax would be:
>>      Proc (In_Param -> A, Out_Param <- B, In_Out_Param <-> C);
>
> How about reusing the mode keywords:
>
>    Proc (
>       In_Param  => in A,
>       Out_Param => out B,
>       In_Out_Param => in out C);
>

As another option if you are not afraid about a lot of restrictions, there  
is one which won't make parameters modes visible, but which will surely  
catch any erroneous assumptions on these, due to an assertion on the  
effect of calling it, failing sooner or later:


     -- SPARK way to solve the issue
     -- and to make explicit what it do.

     procedure P
       (A :    out T;
        B : in out T;
        C : in     T);
     --# derives
     --#    A from B, C &
     --#    B from B, C ;


As a bonus, this could even catch far more errors than simply reminding  
parameter modes :-P … but forget about generic packages [1], subtypes [2]  
and many other things.

[1]: library level generic sub‑programs is OK, but this has the  
implication a generic cannot defines types, constants, etc.
[2]: the last time I tried it, only type‑new was allowed, not sure if it's  
still the same now; may check later.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada 2012: In-out parameters for functions

[Yannick Duchêne (Hibou57)]

Le Tue, 07 May 2013 05:59:49 +0200, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
>
>      -- SPARK way to solve the issue
>      -- and to make explicit what it do.

To not count side effects, which are not even visible in any way at the  
sub‑program declaration, so not even declared out/in–out to expect with  
these. Except for SPARK (the same as above with an added side effect with  
read/write involving a global variable):


     E : U; -- Side effect with this.

     procedure P
       (A :    out T;
        B : in out T;
        C : in     T);
     --# global E;
     --# derives
     --#    A from B, C, E &
     --#    B from B, C &
     --#    E from B;


Here, `E` appears at the declaration of `P` and is like declared in‑out  
(`A` derived from `E` means like if it was`in` and `E` derived from `B`  
means like if it was also `out`).


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada 2012: In-out parameters for functions

[Yannick Duchêne (Hibou57)]

Le Tue, 07 May 2013 05:59:49 +0200, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
> [2]: the last time I tried it, only type‑new was allowed, not sure if  
> it's still the same now; may check later.

I've just checked, and it's the opposite; it does not agree with:

     type T1 is range 1 .. 10;
     type T2 is new T1 range 2 .. 9;

and wants it to be:

     type T1 is range 1 .. 10;
     subtype T2 is T1 range 2 .. 9;

This is different with predefined scalar types, the only one it is  
possible to derive from, i.e, this, is allowed:

     type T3 is new Integer range 1 .. 3;


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada 2012: In-out parameters for functions

[AdaMagica]

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.

Re: Ada 2012: In-out parameters for functions

[Randy Brukardt]

"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.

Re: Ada 2012: In-out parameters for functions

[J-P. Rosen]

Le 04/05/2013 01:54, Randy Brukardt a �crit :
> (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.
Checking "in out" in functions will be in the next release of
AdaControl, of course :-).

And I fully agree that you need an *enforced* style guide. You can't
imagine how many violations are left by manual reviews (as I often say:
my clients hate me - when I run AdaControl on their carefully manually
reviewed code).

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Ada 2012: In-out parameters for functions

[Dmitry A. Kazakov]

On Sat, 04 May 2013 08:58:37 +0200, J-P. Rosen wrote:

> And I fully agree that you need an *enforced* style guide.

Anything (reasonable) that can be enforced must be a legality rule, not a
style.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada 2012: In-out parameters for functions

[J-P. Rosen]

Le 04/05/2013 09:21, Dmitry A. Kazakov a �crit :
>> And I fully agree that you need an *enforced* style guide.
> Anything (reasonable) that can be enforced must be a legality rule, not a
> style.
Language rules must be acceptable to a variety of application domains.
Style rule are tuned to the kind of programs you are developing.

Note for example that AdaControl has checks for opposite rules: what is
required for a given domain can be excluded for another one.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Ada 2012: In-out parameters for functions

[Yannick Duchêne (Hibou57)]

Le Sat, 04 May 2013 08:58:37 +0200, J-P. Rosen <rosen@adalog.fr> a écrit:

> Le 04/05/2013 01:54, Randy Brukardt a écrit :
>> (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.
> Checking "in out" in functions will be in the next release of
> AdaControl, of course :-).

Is it OK with Ada 2012? The last time I tried, I encountered multiple  
issues with constructs like Pre/Post being not supported (was raising an  
error). I looked at ASIS source package on Debian repository, but it seems  
to be dated of 2008 or 2010.

> And I fully agree that you need an *enforced* style guide. You can't
> imagine how many violations are left by manual reviews (as I often say:
> my clients hate me - when I run AdaControl on their carefully manually
> reviewed code).

Not in the same area, profile pragmas also help too. That's not about  
style, but kind‑of.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada 2012: In-out parameters for functions

[Simon Wright]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> Le Sat, 04 May 2013 08:58:37 +0200, J-P. Rosen <rosen@adalog.fr> a écrit:
[...]
>> Checking "in out" in functions will be in the next release of
>> AdaControl, of course :-).
>
> Is it OK with Ada 2012? The last time I tried, I encountered multiple
> issues with constructs like Pre/Post being not supported (was raising
> an error). I looked at ASIS source package on Debian repository, but
> it seems to be dated of 2008 or 2010.

ASIS GPL 2012, when built with GCC 4.8.0, understands Pre and Pre'Class.

But - ASIS is built against a specific compiler; does the Debian
compiler understand these aspects? The gcc 4.4 that comes with Debian 6
doesn't understand -gnat12 ...

Re: Ada 2012: In-out parameters for functions

[J-P. Rosen]

Le 04/05/2013 09:40, Yannick Duchêne (Hibou57) a écrit :
> Is it OK with Ada 2012? The last time I tried, I encountered multiple
> issues with constructs like Pre/Post being not supported (was raising an
> error). I looked at ASIS source package on Debian repository, but it
> seems to be dated of 2008 or 2010.
The /next/ release will be ok with Ada 2012, and include some rules
related to the new features. Should be released soon (I hope).

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Ada 2012: In-out parameters for functions

[Keith Thompson]

anon <anon@anon.org> writes:
[...]
> 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.
[...]

Do you have a specific example of a C compiler that supports "in
out" parameters?

The C language itself has always specified pure pass-by-value
for all function parameters.  (No, arrays are not an exception
to that; for details see section 6 of the comp.lang.c FAQ,
<http://www.c-faq.com>.)  Pass-by-reference is easily, though
perhaps a bit clumsily, emulated by passing pointer arguments.
A C compiler certainly *could* support "in out" parameters as an
extension, but I've never heard of one that did.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"