Re: Ada 2012: In-out parameters for functions

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

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