Re: In-Out Parameters for functions

[Hyman Rosen <hyrosen@mail.com>]

Stuart Palin wrote:
> But the premise in many of your other postings in this
> thread seems to be concerned with resolving the case where
> the expression [currently] has an 'ambiguous' value.

Yes.

> As has already been pointed out in this thread, an Ada
> compiler can not determine - simply from its specification -
> whether a function will have a side-effect or not.

Yes.

> Ada seems to have (as
> a matter of pragmatism) chosen not to prohibit certain
> aspects of ambiguity because the potential benefits [in a
> wide range of cases] out-weigh the pitfalls.

Those benefits being?

> allowing compilers to find an optimal implementation order

But you are now talking about finding an optimal implementation
order for an expression involving more than one function call
where the compiler has no access to the body of the functions.
Do you really think that allowing the compiler to pick the order
of the calls will significantly affect the efficiency?

> - including concurrent computation.

I don't see how this can possibly be allowed, unless the compiler
can see the bodies to inline them. The standard allows operands
and arguments to be evaluated in arbitrary order, but concurrent
execution would completely break any functions that accessed common
data structures.

> This may seem even more reasonable if one acknowledges there
> are other cases where ambiguous behaviour can arise - for
> instance data aliasing through parameter passing

Eliminating sources of ambiguity is a good thing even if not all
of them can be removed.

> If your proposal to define the execution order were to be
> adopted, how might a programmer write the Ada code to
> express their intent that they don't care what order the
> expression is executed in

They could not, just as they cannot specify this for sequences
of statements. If you write
     x := a + b;
     y := c + d;
you may not care which statement is executed first, but you have no
way of telling this to the compiler. Either the compiler can figure
this out for itself, or it can't.

> How much do you think this [manual optimization] would add
> to/detract from the clarity of the code?

I think this is non-existent now, and will continue to be so.

> How do you think someone who is writing applications for a
> target that offers high levels of parallel computation would
> feel about it?

They would feel that order of evaluation is completely orthogonal
to their concerns.