Re: ML-like alternatives to out parameters for functions

["Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net>]

> The prefered Ada solution for this particular case is to raise an
> exception for errors, not return a status variable (or discriminant).

I heartily agree that error checking is best done with exceptions. That is
especially true with functions; the proposed specification of Calculate
rules out its use in more complex expressions, such as

    Process( Calculate (Arg, Valid), My_Data );

since we cannot validly use the result of Calculate until the Valid
parameter is checked.

To make the case for "out" parameters in functions, a much better example
would be the random number generators. For example the package
Ada.Numerics.Float_Random declares the function

    function Random (Gen : Generator) return Uniformly_Distributed;

This function returns the next random number in the range 0.0 .. 1.0, using
the state information associated with Gen. I would argue that it would be
far preferable if the random function could be declared as follows:

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

This would be preferable since, by its very nature, a call to Random update
the Generator state. The random number generator package implementations I
know of basically circumvent the 'in' parameter restrictions to update its
parameter value. (If anyone knows of an Ada compiler that does NOT alter the
value of Gen after a call to Random, please post the details!) That suggests
a flaw in the specification of the Random function.

A frequent way to get the effect of "in" / "in out"  function parameters is
to use anonymous access types, e.g.

    function Random (Gen : access Generator) return Uniformly_Distributed;

but there are problems with the access parameter hack.

1)    The functions with access parameters are more of a hassle to call. You
must remember to declare the actual parameters as "aliased" and use the
'Access or 'Unchecked_Access attribute to get the needed access value.

2)    The anonymous access parameter does not distinguish between "out" and
"in out" modes. When compiling a call to this kind of function, the compiler
cannot do the frequently useful check to see if variables that are to be
read have been initialized.

3)    This hack forces the programmer to specify the parameter passing
convention. Granted, in most cases "in out" and "out" parameters are passed
by reference, but it still feels wrong to require it, and to require
programmers working at a high level of abstract to be aware of this
implementation detail.

I fully understand the Ada 83/95 rationale for the requirement that
functions have only "in" parameters. There is the fear that if a function
could change its parameters, we would see code like this

      x + f(x)

where the result would depend on which order the operands were evaluated.
One wishes that this is only a hypothetical concern, but in my career I have
seen expressions this bad in professional software that I had to maintain,
including a C expression like

    a[i++] = b[i] + offset;

or the PL/1 expression

    fp, fp->prev = fp->next;

It is understandable that the language designers wish to prohibit these
atrocities, but the restriction on function parameters seems to have
backfired. It is time this restriction is removed.