Re: ML-like alternatives to out parameters for functions

Re: ML-like alternatives to out parameters for functions

[Alexandre E. Kopilovitch]

Frank J. Lhota (NOSPAM.lhota.adarose@verizon.net) wrote:
>In most cases, parameter modes are an aid to both the compiler and the
>programmer, telling them when we can assume that an actual parameter could
>be altered and when its state will remain the same. In the case of the
>Random function, however, the parameter mode is a lie. The function
>specification indicates that the Gen parameter is not modified by a call to
>Random, even though we all know that it does indeed get modified. This is an
>inelegant kludge,
>...
Yes, it certainly looks like a kludge. This is even more annoying because (as
it was once explained in Ada-Comment list) there are good reasons for that
solution for the Random (some tasking issues, I recall).
  It seems that for such cases, a real cure should not be permission of IN OUT
parameters for functions (this is a separate issue, and it is, perhaps, locked
for ages... it deserves at least a separate section at the AdaPower site -:) .
  Let's introduce new parameter mode, say, PASS mode, which is applicable for
access parameters only. With this mode one can pass an access parameter to a
subroutine, explicitly stating that this is access for update, while IN mode
will not give permission for update.


Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

ML-like alternatives to out parameters for functions

[Mark Lorenzen]

There has lately been some discussions about Ada's missing
capabilities for specifying out parameters for functions. Apparently
this is a needed feature and an AI (AI-323) has been issued.

An out parameter can be used when the validity of the result of
evaluating a function is not always well-defined. For example:

function Calculate (Argument : in AT; Result_Valid : out Boolean) return RT;


Use of the function could be as:

Result := Calculate (Arg, Valid);
if Valid then
  .. do stuff with Result ..
else
  .. handle error ..
end if;


It seems to me that using a discriminated record type as return type
in order to mimic ML's Option datatype could solve such a (frequently)
occurring problem. But of course I am not the first to come up with
this suggestion, so what is wrong with it? Is it too slow?

The package spec is shown below and should be self-explanatory.

Regards,
- Mark Lorenzen

generic
   type Value_Type is private;
package Optional_Value is

   type Optional_Value_Type is private;

   Undefined_Value : exception;

   function Some
     (Value : in Value_Type)
     return Optional_Value_Type;

   function None
     return Optional_Value_Type;

   -- May raise Undefined_Value;
   function Value_Of
     (Element : in Optional_Value_Type)
     return Value_Type;

   function Is_Defined
     (Element : in Optional_Value_Type)
     return Boolean;

private

   type Optional_Value_Type (Defined : Boolean := False) is
      record
        case Defined is
           when True  =>
              Value : Value_Type;
           when False =>
              null;
        end case;
      end record;

end Optional_Value;

Re: ML-like alternatives to out parameters for functions

[Stephen Leake]

Mark Lorenzen <mark.lorenzen@ofir.dk> writes:

> An out parameter can be used when the validity of the result of
> evaluating a function is not always well-defined. For example:
> 
> function Calculate (Argument : in AT; Result_Valid : out Boolean) return RT;

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

-- 
-- Stephe

Re: ML-like alternatives to out parameters for functions

[Mark Lorenzen]

Stephen Leake <Stephen.A.Leake@nasa.gov> writes:

> Mark Lorenzen <mark.lorenzen@ofir.dk> writes:
> 
> > An out parameter can be used when the validity of the result of
> > evaluating a function is not always well-defined. For example:
> > 
> > function Calculate (Argument : in AT; Result_Valid : out Boolean) return RT;
> 
> The prefered Ada solution for this particular case is to raise an
> exception for errors, not return a status variable (or discriminant).

It sure is. But if the problem being solved does not necessarily have
a solution (and we can't determine if a solution exists before trying
to solve it), then we would like to have a qualifier stating if a
solution could be found or not. The C-way of doing this is typically
to supply the address of a validity flag, that the function can set
before returning a possible solution.

Am I wrong to assume that the Ada-way is definitely to use the
discriminated return type, even in the case that Ada may get out
parameters for functions? The reason for my question is that I have
not seen this approach in Ada before. The solutions I have seen used a
procedure like:

procedure Proc (Arg : in AT; Result : out RT; Validity : out Boolean);

which is just a variant of the C hack and definately not beautiful.

- Mark Lorenzen

Re: ML-like alternatives to out parameters for functions

[John R. Strohm]

"Mark Lorenzen" <mark.lorenzen@ofir.dk> wrote in message
news:m365qhh8ju.fsf@valhal.vikingnet...
> Stephen Leake <Stephen.A.Leake@nasa.gov> writes:
>
> > Mark Lorenzen <mark.lorenzen@ofir.dk> writes:
> >
> > > An out parameter can be used when the validity of the result of
> > > evaluating a function is not always well-defined. For example:
> > >
> > > function Calculate (Argument : in AT; Result_Valid : out Boolean)
return RT;
> >
> > The prefered Ada solution for this particular case is to raise an
> > exception for errors, not return a status variable (or discriminant).
>
> It sure is. But if the problem being solved does not necessarily have
> a solution (and we can't determine if a solution exists before trying
> to solve it), then we would like to have a qualifier stating if a
> solution could be found or not. The C-way of doing this is typically
> to supply the address of a validity flag, that the function can set
> before returning a possible solution.

Well, it really depends on what it means to the rest of the application that
the problem being solved does not necessarily have a solution.

In my personal opinion, raising an exception is still the right thing to do,
in that it forces the caller to recognize that the solution is invalid and
deal with it.  The standard C library routines are notorious for returning
all kinds of status that says the main answer is invalid, and C programmers
are notorious for ignoring those return flags.  (When was the last time you
checked the return status on a printf(), for example?)

Re: ML-like alternatives to out parameters for functions

[Preben Randhol]

Mark Lorenzen wrote:
> 
> procedure Proc (Arg : in AT; Result : out RT; Validity : out Boolean);
> 
> which is just a variant of the C hack and definately not beautiful.

What makes this :

function Calculate (Argument : in AT; Result_Valid : out Boolean) return RT;

anymore beautiful?

If you need to check if some return was valid I cannot see why one
should use a function. If it just so that one can write:

   Rt_Var := Calculate (Some_AT, Success);

then this is more C hack-flavoured to me than using 

   Calculate (Some_AT, Rt_Var, Success);

-- 
Preben Randhol ----------------  http://www.pvv.org/~randhol/     ._.
Debian 3.0 |"Don't think about domination, think about freedom,  / _,\
GNU/Linux  | it doesn't dominate." - Richard M. Stallman        | (_./
><> ><> ><>| To learn more visit => http://www.debian.org/       \,_

Re: ML-like alternatives to out parameters for functions

[tmoran]

> Am I wrong to assume that the Ada-way is definitely to use the
> discriminated return type, even in the case that Ada may get out
  Any time you have two variables which only make sense together
but not separately, you have, conceptually, a single object.  That
can be modelled nicely in this case with a discriminated record.
If you treat them as two separate things, there is always a significant
danger of erroneously letting them get out of sync with each other.
  If profiling demonstrates that returning a discriminated record is
too slow for the app, then it may be worth while to go to in-lining
the calculation, separate variables, assembly language, etc.

Re: ML-like alternatives to out parameters for functions

[Frank J. Lhota]

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

Re: ML-like alternatives to out parameters for functions

[Mark Lorenzen]

"Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> writes:

...snip...

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

But again this relies on side-effects on it's parameters. I would go
for a solution like this:

function Random (Gen : in Generator) return Random_Continuation

where

type Random_Continuation is
  record
    Gen   : Generator;
    Value : Uniformly_Distributed;
  end record;

Coming from an ML world, the use of side-effects on subprogram
parameters seems ackward, but I understand that it may be necessary for
performance reasons.

Another example, this time a shortest path algorithm:

function Shortest_Path
  (From_Node : in Node; To_Node : in Node; In_Graph : in Graph)
  return Path;

If From_Node = To_Node, then an empty Path should be returned. But
what if there does not exist a path between From_Node and To_Node?
Should an exception be raised (No, it is not necessarily an
error). Should a non-path value be returned (Yes):

type Optional_Path (Defined : Boolean) is
  record
    case Defined is
      when True  => P : Path;
      when False => null;
    end record;

The style is the purely functional and it avoids the use of an out
mode parameter as validity flag.

So my question is again: Is it the Ada-way to program in a purely
functional style, or is it (for performance reasons) better to use an
imperative style with side-effects on parameters. This is unrelated to
using exceptions in case of errors.

- Mark Lorenzen

Re: ML-like alternatives to out parameters for functions

[Frank J. Lhota]

"Mark Lorenzen" <mark.lorenzen@ofir.dk> wrote in message
news:m31y14bj83.fsf@valhal.vikingnet...
> But again this relies on side-effects on it's parameters. I would go
> for a solution like this:
>
> function Random (Gen : in Generator) return Random_Continuation
>
> where
>
> type Random_Continuation is
>   record
>     Gen   : Generator;
>     Value : Uniformly_Distributed;
>   end record;

There are two problems with this approach. One is that it assumes that
Generator is not a limited type; currently Generator is limited. But even if
we change the declaration of Generator, this version of Random places a
heavy burden on the caller. In almost all cases, users of this function
simply want to get the next random number and update the generator. With
this version of Random, this can be accomplished only be doing something
like this:

   declare
      Temp : constant Random_Continuation := Random( Gen );
   begin
      Gen   := Temp.Gen;
      Value := Temp.Value;
   end;

Do you really want to require this for every call to Random?

Another possible solution would be to implement Random as a procedure, i.e.

   procedure Random( Gen   : in out Generator;
                     Value :    out Uniformly_Distributed );

This approach would probably the best approach given the current Ada 95
restrictions, since it specifies precisely how Random works: it updates the
generator and returns a value. For ease of use, however, it would be hard to
beat the function solution with the "in out" parameter (if it only were
legal Ada!).

Re: ML-like alternatives to out parameters for functions

[Robert I. Eachus]

Frank J. Lhota wrote:

> This approach would probably the best approach given the current Ada 95
> restrictions, since it specifies precisely how Random works: it updates the
> generator and returns a value. For ease of use, however, it would be hard to
> beat the function solution with the "in out" parameter (if it only were
> legal Ada!).

Let's not revisit this again.  During the Ada 9X development process, 
the arguments on both sides were explained, and a formal WG9 vote taken 
(by countries--this is ISO).  Allowing function parameters to have an in 
out mode was defeated.

Note that this does not mean you cannot write functions in Ada that 
alter their parameters.

    function Random(Gen: in Generator) return Uniformly_Distributed is
      Local_Gen: Generator;
      for Local_Gen'Address use Gen'Address;
    begin...

is perfectly legal Ada.  Note that in this particular case, since 
Generator is a limited type, it is only legal inside the body of the 
package that defines Generator (Presumbably Ada.Numerics.Float_Random, 
but you can write your own random number generators.  I do. ;-)

And that should make the reason why things have stayed the way they are 
perfectly clear.  There is a workaround for the cases where it is 
appropriate to work around the restriction, and the workaround is 
limited in a useful way.  You don't want users poking around inside the 
Generator object, and such poking around--by say passing the Generator 
object to a unit written in C--is flagged with warnings all around.

Re: ML-like alternatives to out parameters for functions

[Frank J. Lhota]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message
news:3E890A20.8080108@attbi.com...
> Note that this does not mean you cannot write functions in Ada that
> alter their parameters.
>
>     function Random(Gen: in Generator) return Uniformly_Distributed is
>       Local_Gen: Generator;
>       for Local_Gen'Address use Gen'Address;
>     begin...
>
> is perfectly legal Ada.

It may be legal code, but the question arises as to whether this is good
code. In most cases, parameter modes are an aid to both the compiler and the
programmer, telling them when we can assume that an actual parameter could
be altered and when its state will remain the same. In the case of the
Random function, however, the parameter mode is a lie. The function
specification indicates that the Gen parameter is not modified by a call to
Random, even though we all know that it does indeed get modified. This is an
inelegant kludge, and it stands out as a blemish on the predefined packages,
which for the most part are very well designed.

Re: ML-like alternatives to out parameters for functions

[Dmitry A. Kazakov]

On 17 Mar 2003 23:17:12 +0100, Mark Lorenzen <mark.lorenzen@ofir.dk>
wrote:

>There has lately been some discussions about Ada's missing
>capabilities for specifying out parameters for functions. Apparently
>this is a needed feature and an AI (AI-323) has been issued.
>
>An out parameter can be used when the validity of the result of
>evaluating a function is not always well-defined. For example:

[snip]

>generic
>   type Value_Type is private;
>package Optional_Value is

[snip]

>   type Optional_Value_Type (Defined : Boolean := False) is
>      record
>        case Defined is
>           when True  =>
>              Value : Value_Type;
>           when False =>
>              null;
>        end case;
>      end record;

This won't work if Value_Type is unconstrained.

The beauty of Ada's functions is that they are capable to return
objects of unknown size, discriminants, specific type. Procedures lack
this very important (especially when class-wide objects are concern)
feature.

So ether (1) functions should be allowed to have in-out parameters, or
(2) procedures should be allowed to have a result.

I prefer 2 and, maybe, a RM statement that an impure function is a
bounded error.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: ML-like alternatives to out parameters for functions

[Preben Randhol]

Mark Lorenzen wrote:
> There has lately been some discussions about Ada's missing
> capabilities for specifying out parameters for functions. Apparently
> this is a needed feature and an AI (AI-323) has been issued.
> 
> An out parameter can be used when the validity of the result of
> evaluating a function is not always well-defined. For example:
> 
> function Calculate (Argument : in AT; Result_Valid : out Boolean) return RT;
> 
> 
> Use of the function could be as:
> 
> Result := Calculate (Arg, Valid);
> if Valid then
>   .. do stuff with Result ..
> else
>   .. handle error ..
> end if;

Or you could do 

function Calculate (Argument : in AT; Result : out RT) return boolean;

Use of the function could be as:

if Calculate (Arg, Result) then
  .. do stuff with Result ..
else
  .. handle error ..
end if;

-- 
�Don't use C;  In my opinion,  C is a library programming language
 not an app programming language.�  - Owen Taylor (GTK+ developer)

Use Ada 95, a free language. More info at http://www.adapower.com/

Re: ML-like alternatives to out parameters for functions

[Mark Biggar]

Mark Lorenzen wrote:
> There has lately been some discussions about Ada's missing
> capabilities for specifying out parameters for functions. Apparently
> this is a needed feature and an AI (AI-323) has been issued.

Unfortunatly, the last ARG meeting voted AI-323 "No Action"
so it is dead and will not be included in the amendment
set for the 0X version of the language.

-- 
Mark Biggar
mark@biggar.org
mark.a.biggar@attbi.com