Why constructing functions is a mess [was Language lawyer question: task activation (was: Language lawyer question: task activation))

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

On Fri, 27 Feb 2009 17:29:10 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1vcaimc8kjj30$.kf3rsd670ebp$.dlg@40tude.net...
> ...
>>> When a procedure P(Object: out T) returns, there
>>> is a yield (in Object).
>>
>> No, it is not so. The actual of Object out T is constructed *prior* to 
>> call to P. In contrast the "actual" of F return T is not constructed (when T is
>> limited). This is exactly the thing that worries me. Because it makes out 
>> T and return T different, while they are evidently same.
> 
> To you, maybe, but not in Ada. Even in Ada 83, "out T" and "return T" are 
> different:
> 
>    procedure Foo (P : out String);
>    function Bar return String;
> 
> Bar creates a *new* object with unknown bounds; Foo takes an *existing* 
> object with whatever bounds it has. Totally different animals.

It is not the difference I am talking about. Your example refers to the
types (the constraints of) of the objects, not about whether the objects
are constructed or not. The actual of an out parameter is required to be
constrained, obviously.

> Build-in-place is a rather natural extension to this model. (It's annoying 
> that we don't have a way to do return-by-reference as well, but that's 
> another topic).
> 
> Now, I realize you have rather firm ideas about what represents a "proper 
> type model", but that's pretty much irrelevant to the Ada type model (which 
> isn't going to change for obvious compatibility reasons).

No, "proper" merely means self consistent.

The problem with constructing functions is that they are inconsistent.
Whatever number of ridiculous constructions (return statement, limited
aggregate etc) you would add, the mess will show itself. 

As a result they would break almost every aspect of Ada as a safe, clean
language.

We saw what happens with tasks returned by a return statement. They break
the contract. Nice. Now a puzzle to you.

Topic: large system design, information hiding:

      type T (<>) is abstract tagged limited private;
   private
      type T (...constraints...) is abstract tagged limited record
         ...
      end record;

In order to be used in

   type S is new T with ...;
   function Create (....) return S;

Fine? No!

How to write Create, the constructing function? See? As a constructor it
has to call Create of T. In this case it must do it because where you get
the discriminants of T otherwise? But you cannot declare Create on T at all

   function Create return T;  -- You cannot return abstract object!

Remember? Constructor is not function. It never will. See the problem?
There are constructors that do not produce objects, while any function
does. So far. Probably there already is an AI to return abstract objects,
which do not exist, or maybe exist, but have some comic accessibility
rights etc. It is like the Big Bang, a little inconsistency gives a whole
universe of MESS...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de