Re: ML-like alternatives to out parameters for functions

[Mark Lorenzen <mark.lorenzen@ofir.dk>]

"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