Re: DYNAMIC ADA TASK CREATION?

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

On Sat, 28 Jun 2003 07:25:02 GMT, "Robert I. Eachus"
<rieachus@attbi.com> wrote:

>I wrote:
>>>  There are times when a programmer will create an object type that 
>>>contains tasks.  And he may want to use, say, a container package for 
>>>objects of this type. (Yes, most container libraries refuse to work with 
>>>limited data objects, but not all.)
>
>Matthew Heaney wrote:
>> The new release of the Charles library does indeed work with element
>> types that are limited.  The basic idea is that when you insert an
>> element into the container, the element is allocated with its default
>> value -- whatever that means for the element type.  For example, for
>> an element type that is controlled, controlled initialization will
>> occur.
>
>Not quite what I had in mind, but great.  I was thinking of container 
>packages that manage references/access values, assuming that the 
>original objects cannot be moved or changed.  When I need a package like 
>this, I usually encapsulate a "normal" container library around a 
>limited type and an explicit access type:
>
>    generic
>      type Element is limited private;

A short question. Why not:

   type Element (<>) is limited private;

[I am using this in my containers because it is weaker than just
limited private.]

>      type Pointer is access Element;
>    package Limited_Stack is
>      procedure Push(E: in Element);
>      procedure Push(P: in Pointer);
>      function Peek return Pointer;
>      function Pop return Pointer;
>      function Pop return Element; -- constant view...
>    end Limited_Stack;
>
>The explicit access type is because of the rules on return by reference 
>providing a constant view.  I may propose as an Ada 0Y revision allowing 
>return by reference functions where a view conversion would be allowed. 
>  In other words, you could have a return by reference function as an in 
>out parameter in another call.  It seems that should be part of AI-318, 
>but AI-318 goes a lot further without addressing this at all. An 
>alternative would be allowing a function to return an anonymous access type.

Or both! Returned anonymous access type could be very useful for
tagged types, because it would make operations returning a pointer
primitive and covariant, which is presently impossible.

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