Re: Ada 2012: In-out parameters for functions

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

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