Re: Ada style of passing 'in' parameters considered dangerous?

["James S. Rogers" <jimmaureenrogers@worldnet.att.net>]

"Antti Sykari" <jsykari@gamma.hut.fi> wrote in message
news:86isvuzabx.fsf@hoastest1-8c.hoasnet.inet.fi...
> Hello,
>
> I recently asked in comp.compilers advice about implementing a
> parameter passing policy for a rather close-to-machine language.  My
> suggestion for the method of passing 'in' parameters to procedures
> was:  Pass everything as readonly by default, and leave the
> by-reference/by-copy decision to the compiler.
>
> It was pointed out that Ada already has this kind of policy.  In one
> reply (<03-01-169@comp.compilers>), it was mentioned that it is a
> time-bomb in Ada, since it permits the programmer to write code that
> is erroneous but the compiler cannot detect this.  Indeed, the
> standard ([1]) says that if an object has been passed via an
> unspecified parameter passing mechanism, is written via one access
> path and read via another, "possible consequences are that
> Program_Error is raised, or the newly assigned value is read, or some
> old value of the object is read".
>
> For example, in the simplest case, a procedure can take a readonly
> 'in' argument "arg1" of type X, and an "in out" argument of the same
> type. Then, if it writes in arg2 and after that reads arg1, this might
> cause a run-time error or other implementation-defined behavior -- but
> only if the procedure is called with two identical arguments.
>
> Of course, the erroneous behavior might occur in a more subtle way,
> which is not expected to happen.  I just can't think of any realistic
> example where this undefinedness would really hurt.
>
> My concerns here are:
>
> - Is this generally considered a dangerous thing in Ada (or in
>   general)?
>
> - Have you encountered a non-trivial real-life case where the
>   programmer has shot himself in the foot in the form of
>   implementation-defined behavior because of the error mentioned above?
>   I'd be interested to hear of any such cases.
>
> - If there are such cases, could it have been prevented by having
>   different policy in the language?  Do you think it would've been
>   better to force the programmer to specify the parameter passing
>   mechanism, for example?

Not at all.

In Ada an IN parameter is treated as a constant within the subprogram
it is passed to. This eliminates the ability to shoot yourself in the foot
with an IN parameter. An OUT or IN OUT parameter can be passed
by value or by reference. The language provides no rules about this.
The difference between the two in Ada is that an OUT parameter
has no reliable initial value, while an IN OUT parameter does.
In fact compiler writers are quite reasonable about their chosen
passing mechanisms. In general, any value larger than a register
is passed by reference. All other values may be passed by copy
or by reference.

There can be no race condition for either situation in a normal
subprogram, since the called subprogram will execute in the
same task as the calling subprogram.

Calling a task entry may involve passing data. This is a form
of communication between tasks. In Ada this happens as part
of a "rendezvous", where the two tasks synchronize at the point
of communication, again eliminating a race condition.

Calling a protected operation is another option for inter-task
communication. Again, protected operations execute within
the calling task, or its proxy in the case of protected entries.

I have never seen a case where Ada parameter modes have
shot the programmer in the foot. Ada parameter passing modes
are a lot safer to use than the rules found for Java. In Java all
primitive types are passed by value and all objects are passed
by reference. You have no choice. This does cause genuine
problems in program design for Java, particularly when you
want to modify the value of a primitive parameter. Since it is
impossible to pass an object by value you have the ever present
danger of unexpected side effects in Java method calls.

Java does not have a direct equivalent of the Ada rendezvous,
nor does it provide an equivalent of Ada protected operations.
Java produces concurrency with a lot more surprises.

Jim Rogers