Re: Reprise: 'in out' parameters for functions

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

Martin Krischik wrote:

> Dmitry A. Kazakov wrote:
> 
>> Florian Weimer wrote:
>> 
>>> Stephen Leake <stephen_leake@acm.org> writes:
>>> 
>>>> Ada has a wart. Let's admit it, and move on.
>>> 
>>> Can't we fix that one without breaking backwards compatibility?
>> 
>> procedure Has_A_Result (...) return Result;
> 
> This solution would call for precise documentation (advantages,
> disadvantages) etc. pp. Plus a quick summary ("functions are faster") for
> the beginner.
>
> Otherwise the same problems as with "access all" will arise. Many
> programers use "access all" all the time - even when not needed, ignoring
> the diadvantages.

This is very true. And there is also a nasty problem with specific access
types for beginners:
 
   type Root is tagged ...;
   type Handle is access Root'Class;

   type Derived is new Root with ...;
   type Derived_Ptr is access Derived;

function Factory return Handle is
   Ptr : Derived_Ptr := new Derived;
begin
   Prepare (Ptr.all);
   return Handle (Ptr); -- Error!
end Factory;

Should cast:

function Factory return Handle is
   Ptr : Handle := new Derived;
begin
   Prepare (Derived (Ptr.all));
   return Ptr;
end Factory;

>>> Or are politics involved?
>> 
>> I think so. But there also is the problem of evaluation order, though
>> simply ignored for access parameters of functions.
> 
> See above. Have you heard of GNATs "pragma Pure_Function"?

Yes, it is a very good thing. I'd like to see it in the standard and
moreover not as a pragma, but as a part of the syntax (in the contract). It
could be very useful, for example, to declare an abstract function as pure,
to force any implementation to conform. Even more useful would be to allow
pure functions in static expressions. The compiler could get an advantage
from knowing that a function is pure:

while Match (Pattern ("..."), Standard_Input) loop
   ... -- Pattern is pure, so the result is a constant
end loop; 

> Prehaps making function even more restive plus procedures with return plus
> a "functions are faster" statement might do the trick.

I think that one should also either 1) fix evaluation order for non-pure
functions and procedures with results or, better, but backward
incompatible, 2) disallow them where the order is not fixed.

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