Re: Mutable parameter of a function (long ago was: Re: What evil would happen?)

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

Robert I. Eachus wrote:

> Dmitry A. Kazakov wrote:
> 
>> No, it is better never use tricks. The Rosen trick is in general an
>> ability for an object to identify itself in all context, even in ones
>> stating something opposite about it. That is an extremely dangerous
>> thing, which breaks substitutability and so the contract. Is this the
>> motivation for exposing this potential contract violation to code
>> maintainer using a pragma? But that would by no means solve the problem.
>> It would make things only worse. It would say, look, this is an
>> in-parameter, but wait, that was just joking, because, here is a pragma,
>> carefully hidden somewhere else, that states the opposite.
> 
> As long as the use does comply with the ADT model it doesn't bother me.
>   This is certainly the case with a random number generator.  The model
> is that calling Random uses the generator but doesn't modify it.

I would object that to use a generator = to modify it (its state), so it
does not comply. If the parameter is a handle to some other object, as it
actually is, because of the Rosen trick, then that should be exposed in the
interface:

function Random (Gen : access Generator) return ...;

IMO the best would be:

procedure Random (Gen : in out Generator) return ...; -- Alas, not Ada!

> There
> are other operations in the random number package that do change the
> generator state, and do have the correct (in out) interface.  (Yes, I
> know that the call really does change some hidden values in the
> generator, but that is equivalent to having a pointer in the generator,
> and changing values in the target of the pointer.
> 
> But if I did have the pragma available, I'd put it in the private part...

The point is that the code reader should see that the random generator is
not a pure function of its argument. This has to be seen immediately from
the specifications, not from a speculation "how-I-would-implement-that".
This is why either the parameter has to be an access or an in-out. Anything
other is wrong, IMO. Similarly the way the operations on File_Type were
declared is IMO wrong!

BTW, this is an example how one error leads to another. The first error was
the design fault of Ada 83, that we had no *procedures* (not functions!)
with return values. The consequent error was to allow access parameters for
functions in Ada 95. The result is completely misleading. Functions
*openly* have side effects, but still have no in-out parameters, forcing
programmers to use pointers (and thus aliased objects).

>> IMO it would be difficult to make it in a consistent way without
>> reviewing the ADT model in Ada. But the time will come, I hope.
> 
> Sort of my point.  It would be nice to "improve" Ada with constant
> subtypes.  But there are a lot more useful things to do first, then see
> if they fit.

I think it would be easier just to add anonymous access-to-constant 
subtypes, and not to try to touch user-defined, named constant subtypes.
The later could be very difficult. One more example:

type X is new Ada.Finalization.Controlled with private;
procedure Initialize (Object : in out X);
procedure Finalize (Object : in out X);

subtype No_No is constant X;

A : No_No; -- Should Initialize raise Constraint_Error, else?
           -- In which contexts Finalize can be called?

This may lead to C++-like nasty rules about special constructor/destructor
contexts etc.

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