Re: Certified C compilers for safety-critical embedded systems

[Stephen Leake <stephen_leake@acm.org>]

Marin David Condic <nobody@noplace.com> writes:

> What exactly would be the meaning of:
> 
> A := Func_X (A) + Func_Y (A) ;

> if functions had in-out parameters and A could be modified while
> evaluating the RHS? 

Obviously, this is erroneous code, since the result depends on the
order of evaluation. Note that it is legal Ada now, if A is an
access parameter. It is similarly erroneous if either Func_X or Func_Y
have other mutually-dependent side effects.

Ada usually tries to eliminate the possibility of such erroneous code.
But given all the ways this statement can be erroneous, I see very
little gain from forbidding "in out".

I guess that's the point of disagreement; how much gain or cost there
is in forbidding "in out".

> Sure, the functions *could* modify A if they
> had visibility to the right scope, but how often does someone do
> that in real-world use? 

All the time in my code, because I need to write reentrant code that
has state.

The canonical example is a random number generator:

function Random (Gen : in out Generator) return Float;

"Obviously", this should be a function (the C and Ada standards say so
:). Also "obviously", it needs to modify the state of the generator.
Not so obviously, that state needs to be stored in the parameter, so I
can call Random from several different threads.

Currently, in non-tricky, legal Ada 95, we cannot simultaneously
satisfy all of the above statements. The only one I'm free to change
is the first one; subprograms that modify state and are reentrant must
be procedures, not functions. (I include using "access" instead of "in
out" as "tricky" code).

All of the Ada 95 implementations must resort to "tricks" to implement
the standard Random. That seems "totally bogus" to me :).

> The current style - while not guaranteeing a lack of side effects -
> tends to discourage it and leads to more easily comprehended code.

Marginally more comprehendable, in some cases. Marginally less
comprehendable, in other cases. This is really a moot point, since we
have access parameters.

Why is making A "access" better than making A "in out"? The parameter
mode is supposed to indicate whether the parameter is modified or not.
It is _not_ supposed to indicate the parameter passing mechanism!

Using "access" instead of "in out" is a form of lying to the user; it
reduces comprehension.

> I don't understand what the headache is here anyway. If one wants to
> modify parameters, use a procedure. 

That is always possible. But why should I not have the choice of using
a function, if it fits the application better?

Why is Random a function?

> If one wants some kind of
> math-oriented thingie to return a result, use a function. 

But I want a function that modifies state in a reentrant way, like
Random does.

> Only interfacing to squirly languages like C seems to be an issue -
> and I think that ought to be a difficult and painful thing to
> discourage it from happening. :-)

Interfacing with C always requires a pragma, so 'pragma
Valued_Procedure' is perfectly reasonable here. I agree that is _not_
an argument for "in out" in functions.

-- 
-- Stephe