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

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"James S. Rogers" <jimmaureenrogers@worldnet.att.net> writes:

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

Unless the actual parameter is aliased with some global, or some other
parameter (of mode 'in out' or 'out').

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

The rule is that elementary types are passed by copy (including copy-out
in the 'in out' or 'out' case).  Arrays and records leave the compiler a
choice (except in the case of limited types).  And that choice can make
a difference in the behavior of the program, unfortunately.

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

The issue arises without any multi-tasking.  But in the multi-task case,
it's even worse: an integer is passed by copy (thus no other task can
meddle with the actual), but a record containing a single integer might
be passed either way.

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

Would it not be better if we could say, "It is not possible to shoot
oneself in one's foot"?

>...Ada parameter passing modes
> are a lot safer to use than the rules found for Java.

Yes, in Java everything's a pointer, so any procedure can modify any of
its parameters (more or less).  Ada is better in that regard.

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

- Bob