Why was it done this way ?

Why was it done this way ?

[Heimlich Manure]

Hello respectable group,

This may be a silly question but I'm sure there was reasoning behind
allowing such :

with Ada.Text_IO;
use Ada.Text_IO;

procedure My_Example is
    task type T1;
    task type T2;

    task body T1 is
    begin
        Put_Line("Instantiating T2 from T1");
        declare
            T_2_2 : T2;
        begin
            null;
        end;
        end T1;

     task body T2 is
     begin
        Put_Line("Instantiating T1 from T2");
        declare
            T_1_1 : T1;
        begin
            null;
        end;
    end T2;

T_1 : T2;
begin
    null;
end My_Example;

Question is, why is this legit ?

Re: Why was it done this way ?

[jimmaureenrogers]

Heimlich Manure wrote:
> Hello respectable group,
>
> This may be a silly question but I'm sure there was reasoning behind
> allowing such :
>
> with Ada.Text_IO;
> use Ada.Text_IO;
>
> procedure My_Example is
>     task type T1;
>     task type T2;
>
>     task body T1 is
>     begin
>         Put_Line("Instantiating T2 from T1");
>         declare
>             T_2_2 : T2;
>         begin
>             null;
>         end;
>         end T1;
>
>      task body T2 is
>      begin
>         Put_Line("Instantiating T1 from T2");
>         declare
>             T_1_1 : T1;
>         begin
>             null;
>         end;
>     end T2;
>
> T_1 : T2;
> begin
>     null;
> end My_Example;
>
> Question is, why is this legit ?

What do you think should be wrong with this?

Think of instances of tasks as active objects.
Each task creates an instance of the other task.

Granted, this program will run forever until the
stack exhausted. In that manner, this program is
a little like a recursive algorithm with no
terminating condition.

Jim Rogers

Re: Why was it done this way ?

[Heimlich Manure]

Well, recursion would explain some but not all of it. Something like

task type T1;
task body T1 is
    MyGhost : T1;

is illegal. Meanwhile,

task type T1;
type T1_Ptr is access T1;
task body T1 is
    MyGhostPtr : T1_Ptr;

is legal. But initializing MyGhostPtr can't be done, obviously, because T1
is unmentionable within its own scope.

Or even worse :

task type T1;
type T1_Ghost is new T1;
task body T1 is
    MyGhostPtr : T1_Ghost;

Even this is legal !

So I humbly sense an inconsistency in "dynamicness" of tasks - it should
either allow full throttle recursion, or detect such loops at compile-time
and barf. But I beg to be forgiven, I just started looking at Ada a week
ago.



<jimmaureenrogers@worldnet.att.net> wrote in message
news:1130380243.198117.318920@g14g2000cwa.googlegroups.com...
>
> Heimlich Manure wrote:
> > Hello respectable group,
> >
> > This may be a silly question but I'm sure there was reasoning behind
> > allowing such :
> >
> > with Ada.Text_IO;
> > use Ada.Text_IO;
> >
> > procedure My_Example is
> >     task type T1;
> >     task type T2;
> >
> >     task body T1 is
> >     begin
> >         Put_Line("Instantiating T2 from T1");
> >         declare
> >             T_2_2 : T2;
> >         begin
> >             null;
> >         end;
> >         end T1;
> >
> >      task body T2 is
> >      begin
> >         Put_Line("Instantiating T1 from T2");
> >         declare
> >             T_1_1 : T1;
> >         begin
> >             null;
> >         end;
> >     end T2;
> >
> > T_1 : T2;
> > begin
> >     null;
> > end My_Example;
> >
> > Question is, why is this legit ?
>
> What do you think should be wrong with this?
>
> Think of instances of tasks as active objects.
> Each task creates an instance of the other task.
>
> Granted, this program will run forever until the
> stack exhausted. In that manner, this program is
> a little like a recursive algorithm with no
> terminating condition.
>
> Jim Rogers
>

Re: Why was it done this way ?

[Steve]

"Heimlich Manure" <spam@goes.here> wrote in message 
news:%DV7f.13378$rE2.2085@fe10.lga...
> Hello respectable group,
>
> This may be a silly question but I'm sure there was reasoning behind
> allowing such :
>
> with Ada.Text_IO;
> use Ada.Text_IO;
>
> procedure My_Example is
>    task type T1;
>    task type T2;
>
>    task body T1 is
>    begin
>        Put_Line("Instantiating T2 from T1");
>        declare
>            T_2_2 : T2;
>        begin
>            null;
>        end;
>        end T1;
>
>     task body T2 is
>     begin
>        Put_Line("Instantiating T1 from T2");
>        declare
>            T_1_1 : T1;
>        begin
>            null;
>        end;
>    end T2;
>
> T_1 : T2;
> begin
>    null;
> end My_Example;
>
> Question is, why is this legit ?
>

Why would it not be legit?

It looks kind of like infinite recursion involving tasks to me.

Probably not something you would want to do, but expecting a lot for the 
compiler to detect the condition.  If the compiler did detect the condition, 
the most I would hope for is a warning... after all it may have been the 
intent.

Steve
(The Duck)

Re: Why was it done this way ?

[Jeffrey R. Carter]

Heimlich Manure wrote:

> Well, recursion would explain some but not all of it. Something like
> 
> task type T1;
> task body T1 is
>     MyGhost : T1;
 >
> is illegal. Meanwhile,

"T1" is not a subtype within T1.

> task type T1;
> type T1_Ptr is access T1;
> task body T1 is
>     MyGhostPtr : T1_Ptr;
> 
> is legal. But initializing MyGhostPtr can't be done, obviously, because T1
> is unmentionable within its own scope.

It's mentionable, but it is not a subtype name.

> Or even worse :
> 
> task type T1;
> type T1_Ghost is new T1;
> task body T1 is
>     MyGhostPtr : T1_Ghost;
> 
> Even this is legal !

T1_Ghost is a subtype name within T1.

Within T1, "T1" refers to the current instance of the type. ARM 9.1: "Within the 
declaration or body of a task unit, the name of the task unit denotes the 
current instance of the unit (see 8.6), rather than the first subtype of the 
corresponding task type (and thus the name cannot be used as a subtype_mark)." 
It turns out to be useful for an instance of a task type to be able to refer to 
itself. This is why these things don't behave the way you seem to expect.

The basic answer to your original question is that the language does not require 
compilers to be smart enough to detect infinite mutual recursion like this, any 
more than it requires that they detect infinite mutual recursion between 
subprograms.

-- 
Jeff Carter
"From this day on, the official language of San Marcos will be Swedish."
Bananas
28

Re: Why was it done this way ?

[Jean-Pierre Rosen]

Heimlich Manure a �crit :
> Well, recursion would explain some but not all of it. Something like
> 
> task type T1;
> task body T1 is
>     MyGhost : T1;
> 
> is illegal. Meanwhile,
> [...]

Ah! You got an error message for the above, and you deduced it was 
illegal to declare a task of the same type within its own body. Not at 
all, it is just a naming issue.

It was felt necessary to be able for a task type to designate itself 
(notably, being allowed to abort itself). Therefore there is a 
convention that within the body of a task type, the type *name* 
designates the currently executing task object (kind of "this" or "self" 
if you want), and hence can't be used to declare another object.

But this is just an issue of naming; for example, the following is legal:

task type T1;
subtype Another_Name_For_T1 is T1;

task body T1 is
     MyGhost : Another_Name_For_T1;

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Why was it done this way ?

[Georg Bauhaus]

Heimlich Manure wrote:
> Hello respectable group,
> 
> This may be a silly question but I'm sure there was reasoning behind
> allowing such :


pragma Restrictions (No_Task_Hierarchy);


> with Ada.Text_IO;
> use Ada.Text_IO;
> 
> procedure My_Example is
>     task type T1;
>     task type T2;
> 
>     task body T1 is
>     begin
>         Put_Line("Instantiating T2 from T1");
>         declare
>             T_2_2 : T2;
> ...

> Question is, why is this legit ?


I think it might be difficult in general to detect mutual
recursion, but IANALL ...

Re: Why was it done this way ?

[Robert A Duff]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> I think it might be difficult in general to detect mutual
> recursion, but IANALL ...

It is a language design principle that the compiler should be able to
detect legality errors by looking only at the current compilation unit,
and things it depends upon semantically.  In particular, the compiler
shouldn't have to look at other package bodies.  The mutually recursive
tasks could be separately compiled.  There are a few exceptions to
this principle (see "Post-Compilation Rules" in the RM).  These are
deliberately kept to a minimum.

As JPR pointed out, the goal of the rule (that the task type name
denotes the task when inside it) is _not_ to prevent recursion.
It is simply a convenient way to refer to the current instance.
The same rule applies to records and generic units.  The language
could have been designed to have special syntax for this case
(something like "this T1").

Anyway, recursion (mutual or otherwise) of tasks is useful (in rare cases),
so it would be annoying if it were forbidden.  It might be nice
to detect _infinite_ recursion of tasks (or of procedures, for
that matter), but that's impossible in the general case.

I believe GNAT is capable of printing a warning on _some_ infinite
recursions (of procedures).

- Bob