Task discriminants

Task discriminants

[Dave Levy]

Hi

Suppose one has a task type with a discriminant:

    task type A_Task( Id : integer);

and one wishes to declare a set of tasks with initialised discriminants:
    t1 : A_Task(1);
    t2 : A_Task(2);
    t3 : A_Task(3);

How could one declare them as an array of tasks with each one getting an 
initialised discriminant? Perhaps something like:

    The_Tasks: array (1..3) of A_Task( Id => 1,2,3 );

Except I tried this with Gnat and it won't compile.

Thanks

Dave

Re: Task discriminants

[David C. Hoos]

How about:

The_Tasks: array (1 .. 3) of A_Task =
 (A_Task (1),
  A_Task (2),
  A_Task (3)
 );
----- Original Message ----- 
From: "Dave Levy" <dlevy@mail.usyd.edu.au>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada-france.org>
Sent: Thursday, May 20, 2004 9:47 AM
Subject: Task discriminants


> Hi
> 
> Suppose one has a task type with a discriminant:
> 
>     task type A_Task( Id : integer);
> 
> and one wishes to declare a set of tasks with initialised discriminants:
>     t1 : A_Task(1);
>     t2 : A_Task(2);
>     t3 : A_Task(3);
> 
> How could one declare them as an array of tasks with each one getting an 
> initialised discriminant? Perhaps something like:
> 
>     The_Tasks: array (1..3) of A_Task( Id => 1,2,3 );
> 
> Except I tried this with Gnat and it won't compile.
> 
> Thanks
> 
> Dave
> 
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada-france.org
> http://www.ada-france.org/mailman/listinfo/comp.lang.ada
> 

Re: Task discriminants

[Martin Dowie]

function Next_Id return Integer;

task type A_Task (Id : Integer := Next_Id);

Id : Integer := 0;

function Next_Id return Integer is
begin
   Id := Id + 1;
   return Id;
end Next_Id;

The_Tasks : array (1 .. 3) of A_Task;

You could consider putting Id and Next_Id in their own package.

Cheers

-- Martin


"David C. Hoos" <david.c.hoos.sr@ada95.com> wrote in message
news:mailman.1.1085073466.401.comp.lang.ada@ada-france.org...
> How about:
>
> The_Tasks: array (1 .. 3) of A_Task =
>  (A_Task (1),
>   A_Task (2),
>   A_Task (3)
>  );
> ----- Original Message ----- 
> From: "Dave Levy" <dlevy@mail.usyd.edu.au>
> Newsgroups: comp.lang.ada
> To: <comp.lang.ada@ada-france.org>
> Sent: Thursday, May 20, 2004 9:47 AM
> Subject: Task discriminants
>
>
> > Hi
> >
> > Suppose one has a task type with a discriminant:
> >
> >     task type A_Task( Id : integer);
> >
> > and one wishes to declare a set of tasks with initialised discriminants:
> >     t1 : A_Task(1);
> >     t2 : A_Task(2);
> >     t3 : A_Task(3);
> >
> > How could one declare them as an array of tasks with each one getting an
> > initialised discriminant? Perhaps something like:
> >
> >     The_Tasks: array (1..3) of A_Task( Id => 1,2,3 );
> >
> > Except I tried this with Gnat and it won't compile.
> >
> > Thanks
> >
> > Dave
> >
> > _______________________________________________
> > comp.lang.ada mailing list
> > comp.lang.ada@ada-france.org
> > http://www.ada-france.org/mailman/listinfo/comp.lang.ada
> >

Re: Task discriminants

[Georg Bauhaus]

Martin Dowie <martin.dowie@btopenworld.com> wrote:
: You could consider putting Id and Next_Id in their own package.

Or in a protected object.


-- Georg

Re: Task discriminants

[Jeffrey Carter]

Georg Bauhaus wrote:
> Martin Dowie <martin.dowie@btopenworld.com> wrote:
> : You could consider putting Id and Next_Id in their own package.
> 
> Or in a protected object.

A protected object is not required. Invocations of Next_ID are 
guaranteed to be sequential.

-- 
Jeff Carter
"C++ is like jamming a helicopter inside a Miata
and expecting some sort of improvement."
Drew Olbrich
51

Re: Task discriminants

[Phil Slater]

This prompts the question, "are tasks on an array elaborated in order from
low-index to high-index? So is Martin's code below guaranteed to make each
task's discriminant the same as its index on the array? I looked in RM95 but
couldn't locate order of elaboration of array elements.

If so, it's potentially useful for setting up an array of tasks that passes
data up and down the array by each rendezvousing with its neighbours.
(Obviously the start value of Id and the index range of the array have to be
consistent.)

But if the order of elaboration isn't guaranteed, we're back to the old
"roll-call" initialisation rendezvous again.



"Martin Dowie" <martin.dowie@btopenworld.com> wrote in message
news:c8itt3$gkq$1@titan.btinternet.com...
> function Next_Id return Integer;
>
> task type A_Task (Id : Integer := Next_Id);
>
> Id : Integer := 0;
>
> function Next_Id return Integer is
> begin
>    Id := Id + 1;
>    return Id;
> end Next_Id;
>
> The_Tasks : array (1 .. 3) of A_Task;
>
> You could consider putting Id and Next_Id in their own package.
>
> Cheers
>
> -- Martin
>
>
> "David C. Hoos" <david.c.hoos.sr@ada95.com> wrote in message
> news:mailman.1.1085073466.401.comp.lang.ada@ada-france.org...
> > How about:
> >
> > The_Tasks: array (1 .. 3) of A_Task =
> >  (A_Task (1),
> >   A_Task (2),
> >   A_Task (3)
> >  );
> > ----- Original Message -----
> > From: "Dave Levy" <dlevy@mail.usyd.edu.au>
> > Newsgroups: comp.lang.ada
> > To: <comp.lang.ada@ada-france.org>
> > Sent: Thursday, May 20, 2004 9:47 AM
> > Subject: Task discriminants
> >
> >
> > > Hi
> > >
> > > Suppose one has a task type with a discriminant:
> > >
> > >     task type A_Task( Id : integer);
> > >
> > > and one wishes to declare a set of tasks with initialised
discriminants:
> > >     t1 : A_Task(1);
> > >     t2 : A_Task(2);
> > >     t3 : A_Task(3);
> > >
> > > How could one declare them as an array of tasks with each one getting
an
> > > initialised discriminant? Perhaps something like:
> > >
> > >     The_Tasks: array (1..3) of A_Task( Id => 1,2,3 );
> > >
> > > Except I tried this with Gnat and it won't compile.
> > >
> > > Thanks
> > >
> > > Dave
> > >
> > > _______________________________________________
> > > comp.lang.ada mailing list
> > > comp.lang.ada@ada-france.org
> > > http://www.ada-france.org/mailman/listinfo/comp.lang.ada
> > >
>
>

Re: Task discriminants

[Martin Dowie]

"Phil Slater" <phil.slater@amsjv.com> wrote in message
news:40adcdfe_1@baen1673807.greenlnk.net...
> This prompts the question, "are tasks on an array elaborated in order from
> low-index to high-index? So is Martin's code below guaranteed to make each
> task's discriminant the same as its index on the array? I looked in RM95
but
> couldn't locate order of elaboration of array elements.
>
> If so, it's potentially useful for setting up an array of tasks that
passes
> data up and down the array by each rendezvousing with its neighbours.
> (Obviously the start value of Id and the index range of the array have to
be
> consistent.)
>
> But if the order of elaboration isn't guaranteed, we're back to the old
> "roll-call" initialisation rendezvous again.

Difinately one for the language lawyers but _in_the_real_world_ I've yet to
come across a compiler that did anything other than the 'sensible' thing.

Randy are there? :-)

Re: Task discriminants

[Randy Brukardt]

"Martin Dowie" <martin.dowie@btopenworld.com> wrote in message
news:c8kti8$p07$1@titan.btinternet.com...
> "Phil Slater" <phil.slater@amsjv.com> wrote in message
> news:40adcdfe_1@baen1673807.greenlnk.net...
> > This prompts the question, "are tasks on an array elaborated in order
from
> > low-index to high-index? So is Martin's code below guaranteed to make
each
> > task's discriminant the same as its index on the array? I looked in RM95
but
> > couldn't locate order of elaboration of array elements.
> >
> > If so, it's potentially useful for setting up an array of tasks that
passes
> > data up and down the array by each rendezvousing with its neighbours.
> > (Obviously the start value of Id and the index range of the array have
to be
> > consistent.)
> >
> > But if the order of elaboration isn't guaranteed, we're back to the old
> > "roll-call" initialisation rendezvous again.
>
> Difinately one for the language lawyers but _in_the_real_world_ I've yet
to
> come across a compiler that did anything other than the 'sensible' thing.
>
> Randy are there? :-)

The RM says "arbitrary order" for initializing subcomponents of object
declarations (see 3.3.1(20) - this is the "fourth step"). So you can't
depend on it.

OTOH, it's fairly hard to imagine why an implementation would do anything
other than use a loop to do it, which would of course give the right answer.
So practically, it probably would work right.

                            Randy.

Re: Task discriminants

[Martin Dowie]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:YIadnaE4uYUXxjPd4p2dnA@megapath.net...
> > Difinately one for the language lawyers but _in_the_real_world_ I've yet
> to
> > come across a compiler that did anything other than the 'sensible'
thing.
> >
> > Randy are there? :-)
>
> The RM says "arbitrary order" for initializing subcomponents of object
> declarations (see 3.3.1(20) - this is the "fourth step"). So you can't
> depend on it.
>
> OTOH, it's fairly hard to imagine why an implementation would do anything
> other than use a loop to do it, which would of course give the right
answer.
> So practically, it probably would work right.

For once I'd actually spotted that! But when ever I try and quote the RM
there is always some other section that proved me wrong! ;-)

Re: Task discriminants

[Randy Brukardt]

"Martin Dowie" <martin.dowie@btopenworld.com> wrote in message
news:c8luk4$29b$1@hercules.btinternet.com...
> "Randy Brukardt" <randy@rrsoftware.com> wrote in message
> news:YIadnaE4uYUXxjPd4p2dnA@megapath.net...
> > OTOH, it's fairly hard to imagine why an implementation would do
anything
> > other than use a loop to do it, which would of course give the right
> answer.
> > So practically, it probably would work right.
>
> Given this last statement, is it worth changing the RM to make this a
> Confirmation or Implementation Advice or some such?

Well, we'd need a compelling reason to make a change here, because it's
possible that some implementors do use this rule to some advantage. The only
time it matters is when you have side effects during elaboration, which is
generally discouraged anyway.

To solve the problem at hand, I'd suggest the technique that Robert Eachus
demonstrated. It doesn't depend on a majic function or order of evaluation.
Yes, it serializes the initialization of the tasks, but so does the
elaboration mechanism.

                      Randy.

Re: Task discriminants

[Martin Dowie]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:qs2dndOX7I9aEDPdRVn-gw@megapath.net...
> "Martin Dowie" <martin.dowie@btopenworld.com> wrote in message
> > Given this last statement, is it worth changing the RM to make this a
> > Confirmation or Implementation Advice or some such?
>
> Well, we'd need a compelling reason to make a change here, because it's
> possible that some implementors do use this rule to some advantage. The
only
> time it matters is when you have side effects during elaboration, which is
> generally discouraged anyway.

The only thing I can think of that some users are currently taking advantage
of what is partically implemented! :-)

Is there any compiler out that that does not do the 'right thing' - I've
certainly
never come across one.

-- Martin

Re: Task discriminants

[Randy Brukardt]

"Martin Dowie" <martin.dowie@btopenworld.com> wrote in message
news:c8n11h$5qi$1@hercules.btinternet.com...
> "Randy Brukardt" <randy@rrsoftware.com> wrote in message
> news:qs2dndOX7I9aEDPdRVn-gw@megapath.net...
> > "Martin Dowie" <martin.dowie@btopenworld.com> wrote in message
> > > Given this last statement, is it worth changing the RM to make this a
> > > Confirmation or Implementation Advice or some such?
> >
> > Well, we'd need a compelling reason to make a change here, because it's
> > possible that some implementors do use this rule to some advantage. The
> only
> > time it matters is when you have side effects during elaboration, which
is
> > generally discouraged anyway.
>
> The only thing I can think of that some users are currently taking
advantage
> of what is partically implemented! :-)
>
> Is there any compiler out that that does not do the 'right thing' - I've
certainly
> never come across one.

How would you know? Depending on side-effects in elaboration order is
dubious in any case. The only place I've ever seen discriminants initialized
by functions with side-effects is in ACATS tests - it's certainly not a
common style. And, the issue is one of optimization - an implementation
could implement elaboration in unrolled loops or the like in some cases.
Just because it works in some particular case doesn't mean that it will work
in all cases.

                         Randy.

Re: Task discriminants

[Martin Dowie]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:vpGdnbX1YZHq9y_d4p2dnA@megapath.net...
> > Is there any compiler out that that does not do the 'right thing' - I've
> certainly never come across one.
>
> How would you know? Depending on side-effects in elaboration order is
> dubious in any case. The only place I've ever seen discriminants
initialized
> by functions with side-effects is in ACATS tests - it's certainly not a
> common style. And, the issue is one of optimization - an implementation
> could implement elaboration in unrolled loops or the like in some cases.

Spotting when it does do the 'right' thing would be easy during any half
decent testing as the whole point of this is to ensure that the array index
into the task is the same as value as the discriminant.

As to whether the style is common, well, YMMV. :-)

> Just because it works in some particular case doesn't mean that it will
work
> in all cases.

Absolutely! But that was kind of my question - is there any implementation
that won't give the desired result in this case? Not to my knowledge but
then
I don't have access to every implementation...

-- Martin

Re: Task discriminants

[Randy Brukardt]

"Martin Dowie" <martin.dowie@btopenworld.com> wrote in message
news:c8umnc$lqt$1@sparta.btinternet.com...
> "Randy Brukardt" <randy@rrsoftware.com> wrote in message
> news:vpGdnbX1YZHq9y_d4p2dnA@megapath.net...
> > Just because it works in some particular case doesn't mean that it will
work
> > in all cases.
>
> Absolutely! But that was kind of my question - is there any implementation
> that won't give the desired result in this case? Not to my knowledge but
then
> I don't have access to every implementation...

I meant even on a particular implementation. A different setting of
optimization flags, a different expression in the discriminant default, and
an implementation that appears to work on your test program could do
something different. So just because you have some instance of it that works
with some particular set of compiler switches does not mean that that
implementation "gives the desired result" in general. Only your implementor
could really tell you, and even they might not know for sure.

                           Randy.

Re: Task discriminants

[Martin Dowie]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:0pGdnb8KMtY7Ni7dRVn-jw@megapath.net...
> > Absolutely! But that was kind of my question - is there any
implementation
> > that won't give the desired result in this case? Not to my knowledge but
> then
> > I don't have access to every implementation...
>
> I meant even on a particular implementation. A different setting of
> optimization flags, a different expression in the discriminant default,
and
> an implementation that appears to work on your test program could do
> something different. So just because you have some instance of it that
works
> with some particular set of compiler switches does not mean that that
> implementation "gives the desired result" in general. Only your
implementor
> could really tell you, and even they might not know for sure.

Really?!

I'm not sure what you mean by "a different expression in the
discriminant default" - that's always going to be a call to the
function in the example I gave? No?

As to different optimization flags, I would have thought that falls under
the same category "haven't found one yet that does anything other than
the 'sensible' option" - but you never know.

There are other precedents for "polling" to find out what all ARA compiler
vendors do in particular cases - I guess I'd be interested in such a poll.
If
there is already a 'de facto' standard implmentation I don't see any harm
in making it Implementation Advice - I do see the harm in requiring such
behaviour! ;-)

I also recognize that I'm but one (user) voice and that the
ARA/Ada-Comment have better things to do! For me I'm ok with assuming
the 'sensible' option and testing it happens - that may be good enough for
other folks.

Cheers

-- Martin

Re: Task discriminants

[Martin Krischik]

Dave Levy wrote:

> Hi
> 
> Suppose one has a task type with a discriminant:
> 
>     task type A_Task( Id : integer);
> 
> and one wishes to declare a set of tasks with initialised discriminants:
>     t1 : A_Task(1);
>     t2 : A_Task(2);
>     t3 : A_Task(3);
> 
> How could one declare them as an array of tasks with each one getting an
> initialised discriminant? Perhaps something like:
> 
>     The_Tasks: array (1..3) of A_Task( Id => 1,2,3 );
> 
> Except I tried this with Gnat and it won't compile.

Of corse not! Tasks are indefinite type and can't be stored in arrays. You
can store an access to a task in an array.

With Regards

Martin

PS: I could not find anything in the RM: Does anybody know if task are also
limited.

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Task discriminants

[Dmitry A. Kazakov]

On Thu, 20 May 2004 19:30:57 +0200, Martin Krischik
<krischik@users.sourceforge.net> wrote:

>Dave Levy wrote:
>
>> Suppose one has a task type with a discriminant:
>> 
>>     task type A_Task( Id : integer);
>> 
>> and one wishes to declare a set of tasks with initialised discriminants:
>>     t1 : A_Task(1);
>>     t2 : A_Task(2);
>>     t3 : A_Task(3);
>> 
>> How could one declare them as an array of tasks with each one getting an
>> initialised discriminant? Perhaps something like:
>> 
>>     The_Tasks: array (1..3) of A_Task( Id => 1,2,3 );

Ada does not have constructors with parameters, alas.

>> Except I tried this with Gnat and it won't compile.
>
>Of corse not! Tasks are indefinite type and can't be stored in arrays. You
>can store an access to a task in an array.
>
>With Regards
>
>Martin
>
>PS: I could not find anything in the RM: Does anybody know if task are also
>limited.

Task types are indeed limited. This does not prevent us from having
arrays of tasks. A task type as above with an integer discriminant
will be unconstrained not because it is a task, but because Id has no
default value. The solution Martin Dowie proposed shows it.

Though, why one should want an Id discriminant, if there is the
package Ada.Task_Identification?

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

Re: Task discriminants

[Andersen Jacob Sparre]

Dmitry A. Kazakov wrote:

> Though, why one should want an Id discriminant, if there is the
> package Ada.Task_Identification?

It could be that the tasks represented entities with externally
assigned identities.

Greetings,

Jacob
-- 
Scripts for automating parts of the daily
operations of your Linux system:
              http://jacob.sparre.dk/Jacob/edb/tcsh-samling/

Re: Task discriminants

[Robert I. Eachus]

Martin Krischik wrote:

> Of corse not! Tasks are indefinite type and can't be stored in arrays. You
> can store an access to a task in an array.

No, you certainly can have arrays of tasks, even arrays of tasks with 
discriminants.  But you can't have an array of tasks with different 
discriminants, only because there is no way to initialize it.   You can 
wait for Ada 2005, use an array of access types, or if you prefer an 
array of Task_IDs.

> PS: I could not find anything in the RM: Does anybody know if task are also
> limited.

Yes they are.  See RM 9.1(21).

As to solving the problem that started this discussion, my preferred 
solution is to have an array of access values, and have a function that 
initializes the array by creating the (discriminated) tasks and 
returning the array.  You go through a loop of:

for I in 1..Max loop
   Result(I) := new Task_Type(I);
end loop;

That way the task 'knows' its position in the array.  If you have a 
large distributed system though, you want to use a tree where 
Task_Type(J) first registers itself, then creates Task_Type(2*J) and 
Task_Type(2*J+1), assuming that 2*J < Max.  This allows the work of 
creating the tasks can be distributed to multiple processors.

-- 

                                           Robert I. Eachus

"The terrorists rejoice in the killing of the innocent, and have 
promised similar violence against Americans, against all free peoples, 
and against any Muslims who reject their ideology of murder. Their 
barbarism cannot be appeased, and their hatred cannot be satisfied. 
There's only one way to deal with terror: We must confront the enemy and 
stay on the offensive until these killers are defeated." -- George W. Bush

Re: Task discriminants

[Martin Dowie]

"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:gtqdnTKDieX9rzPdRVn-vw@comcast.com...
> for I in 1..Max loop
>    Result(I) := new Task_Type(I);
> end loop;

Slightly better (IMHO)

for I in Result'Range loop
   Result(I) := new Task_Type(I);
end loop;

Re: Task discriminants

[Pascal Obry]

"Robert I. Eachus" <rieachus@comcast.net> writes:

> No, you certainly can have arrays of tasks, even arrays of tasks with
> discriminants.  But you can't have an array of tasks with different
> discriminants, only because there is no way to initialize it.   You can wait
> for Ada 2005, 

I'm currious now, can you point me to the right AI that will make this
possible ?

Thanks,
Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Task discriminants

[Randy Brukardt]

"Pascal Obry" <pascal@obry.org> wrote in message
news:uzn804eq8.fsf@obry.org...
>
> "Robert I. Eachus" <rieachus@comcast.net> writes:
>
> > No, you certainly can have arrays of tasks, even arrays of tasks with
> > discriminants.  But you can't have an array of tasks with different
> > discriminants, only because there is no way to initialize it.   You can
wait
> > for Ada 2005,
>
> I'm currious now, can you point me to the right AI that will make this
> possible ?

I know of no AI that would change anything in this area. I think it's more
likely "wait for Ada 2015".

                        Randy.

Re: Task discriminants

[Robert I. Eachus]

Pascal Obry wrote:

>>No, you certainly can have arrays of tasks, even arrays of tasks with
>>discriminants.  But you can't have an array of tasks with different
>>discriminants, only because there is no way to initialize it.   You can wait
>>for Ada 2005, 
> 
> 
> I'm currious now, can you point me to the right AI that will make this
> possible ?

It will be a side-effect of AI-0318 Returning [limited] objects without 
copying.  Maybe it shouldn't be, but I see nothing to prevent it. 
Personally I don't see any harm to it.  You can do the same sort of 
thing today, but having an array of access values that designate tasks 
or limited objects containing tasks.  The magic that comes from AI-318 
is initializing objects in-place.  So you could have a function that 
returned (in-place) task objects, and a (limited) array that had several 
function calls as its initial value.

-- 

                                           Robert I. Eachus

"The terrorists rejoice in the killing of the innocent, and have 
promised similar violence against Americans, against all free peoples, 
and against any Muslims who reject their ideology of murder. Their 
barbarism cannot be appeased, and their hatred cannot be satisfied. 
There's only one way to deal with terror: We must confront the enemy and 
stay on the offensive until these killers are defeated." -- George W. Bush

Re: Task discriminants

[Nick Roberts]

"Dave Levy" <dlevy@mail.usyd.edu.au> wrote in message
news:40ACC50E.9040406@mail.usyd.edu.au...

> Suppose one has a task type with a discriminant:
>
>     task type A_Task( Id : integer);
>
> and one wishes to declare a set of tasks with initialised discriminants:
>     t1 : A_Task(1);
>     t2 : A_Task(2);
>     t3 : A_Task(3);
>
> How could one declare them as an array of tasks with each one getting an
> initialised discriminant? Perhaps something like:
>
>     The_Tasks: array (1..3) of A_Task( Id => 1,2,3 );
>
> Except I tried this with Gnat and it won't compile.

It is a basic precept of Ada arrays that its components are all of the same
subtype. This means that they cannot have different discriminants. So this
approach, as such, is doomed.

You could use the 'old' technique:

   type A_Task_Number is range 1..3;

   task type A_Task is
      entry Init (Num: in A_Task_Number);
      ...
   end;

   The_Tasks: array (A_Task_Number) of A_Task;

   ...
      for i in A_Task_Number loop
         The_Tasks(i).Init(i);
      end loop;
   ...

   task body A_Task is
      My_Num: A_Task_Number;
      ...
   begin
      accept Init (Num: in A_Task_Number) do
         My_Num := Num;
      end;
      ...
   end A_Task;

It's always worked for me!

-- 
Nick Roberts

Re: Task discriminants

[Karen]

Or the obvious approach, to declare a access type to the task type.  Then
have an array of those access types, which are initialised using different
discriminants as you need.

(from a posting newbie, but an Ada Graybeard)
ian(dot)nussbaum(at)blueyonder.co.uk


"Nick Roberts" <nick.roberts@acm.org> wrote in message
news:2iceofFlgn4pU1@uni-berlin.de...
> "Dave Levy" <dlevy@mail.usyd.edu.au> wrote in message
> news:40ACC50E.9040406@mail.usyd.edu.au...
>
> > Suppose one has a task type with a discriminant:
> >
> >     task type A_Task( Id : integer);
> >
> > and one wishes to declare a set of tasks with initialised discriminants:
> >     t1 : A_Task(1);
> >     t2 : A_Task(2);
> >     t3 : A_Task(3);
> >
> > How could one declare them as an array of tasks with each one getting an
> > initialised discriminant? Perhaps something like:
> >
> >     The_Tasks: array (1..3) of A_Task( Id => 1,2,3 );
> >
> > Except I tried this with Gnat and it won't compile.
>
> It is a basic precept of Ada arrays that its components are all of the
same
> subtype. This means that they cannot have different discriminants. So this
> approach, as such, is doomed.
>
> You could use the 'old' technique:
>
>    type A_Task_Number is range 1..3;
>
>    task type A_Task is
>       entry Init (Num: in A_Task_Number);
>       ...
>    end;
>
>    The_Tasks: array (A_Task_Number) of A_Task;
>
>    ...
>       for i in A_Task_Number loop
>          The_Tasks(i).Init(i);
>       end loop;
>    ...
>
>    task body A_Task is
>       My_Num: A_Task_Number;
>       ...
>    begin
>       accept Init (Num: in A_Task_Number) do
>          My_Num := Num;
>       end;
>       ...
>    end A_Task;
>
> It's always worked for me!
>
> --
> Nick Roberts
>
>