embed accept statement in procedures not possible?

embed accept statement in procedures not possible?

[Gerd]

Hi all,

I work with GNAT 3.15 on Windows XP. My problem is that I want
structure my program in a way that is not accepted by GNAT, but I
cannot understand why.

My code (schematic only):

task t is
  entry e;
end t;

task body t is
  procedure p is
  begin
    accept e;
  end p;
begin
  p;
end t;

GNAT tells me: "enclosing body for accept must be a task". But - the
accept in procedure p _is_ in a task. So why is this not allowed?

My accept statement is a bit longer and needed a few times in
different situations. Therefore I don't want to "copy and paste" this
code directly in the task body.

Gerd

Re: embed accept statement in procedures not possible?

[Jean-Pierre Rosen]

Gerd a �crit :
> My code (schematic only):
> 
> task t is
>   entry e;
> end t;
> 
> task body t is
>   procedure p is
>   begin
>     accept e;
>   end p;
> begin
>   p;
> end t;
> 
> GNAT tells me: "enclosing body for accept must be a task". But - the
> accept in procedure p _is_ in a task. So why is this not allowed?
> 
True. An accept statement must be *immediately* within a task body, not 
in anything enclosed in the task body.

That rule is necessary to ensure that a task can accept only its own 
entries. Your example is of course very simple, but consider that a task 
can be included in another task. What if Inner_Task called your P procedure?
-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: embed accept statement in procedures not possible?

[Adam Beneschan]

On May 4, 9:58 am, Jean-Pierre Rosen <r...@adalog.fr> wrote:
> Gerd a écrit :
>
> > My code (schematic only):
>
> > task t is
> >   entry e;
> > end t;
>
> > task body t is
> >   procedure p is
> >   begin
> >     accept e;
> >   end p;
> > begin
> >   p;
> > end t;
>
> > GNAT tells me: "enclosing body for accept must be a task". But - the
> > accept in procedure p _is_ in a task. So why is this not allowed?
>
> True. An accept statement must be *immediately* within a task body, not
> in anything enclosed in the task body.
>
> That rule is necessary to ensure that a task can accept only its own
> entries. Your example is of course very simple, but consider that a task
> can be included in another task. What if Inner_Task called your P procedure?

Actually, though, why is a syntactic rule necessary (as opposed to a
run-time check)?

Not that I'm proposing a language change.  This is an area I haven't
really given any thought, so I can't say whether the restriction that
prevents "accept" from being done inside a procedure makes life too
burdensome.  But would there be any serious difficulty in changing the
rules so that an "accept" statement is legal inside a procedure, but
raises an exception if the statement is executed under the control of
a task other than the one whose entry is being accepted?  Off the top
of my head (and after about six seconds' worth of thought), I don't
see why this would be unfeasible.

                                         -- Adam

Re: embed accept statement in procedures not possible?

[Jean-Pierre Rosen]

Adam Beneschan a �crit :
> Actually, though, why is a syntactic rule necessary (as opposed to a
> run-time check)?
> 
1) In general, Ada enforces static checking rather than dynamic 
checking, especially when (like here) the problem is really structural

2) There would be a distributed cost. Any accept statement would need to 
access, at least Current_Task, and (believe it or not) this can be 
costly in some environments.

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

Re: embed accept statement in procedures not possible?

[Adam Beneschan]

On May 9, 12:12 am, Jean-Pierre Rosen <r...@adalog.fr> wrote:
> Adam Beneschan a écrit :> Actually, though, why is a syntactic rule necessary (as opposed to a
> > run-time check)?
>
> 1) In general, Ada enforces static checking rather than dynamic
> checking, especially when (like here) the problem is really structural
>
> 2) There would be a distributed cost. Any accept statement would need to
> access, at least Current_Task, and (believe it or not) this can be
> costly in some environments.

I don't think #2 is true.  Any ACCEPT statement that is currently
legal would not have to perform this check, and the compiler would of
course be able to tell statically whether the check would need to be
done or not, since that would be just the same check it's performing
now to enforce the rule.  (And I think there would be cases where a
compiler can tell that no check is needed even for an ACCEPT inside a
procedure.  Off the top of my head, I think this is the case if the
task has no nested task types, 'Access is never used on the procedure,
and the procedure is never used as a generic actual parameter.)

If I'm right and there's no distributed cost, then #1 doesn't provide
enough of a reason to disallow such ACCEPTs.  There may be other
reasons I haven't thought of that would make this a bad idea (perhaps
some implementations need the task body to be the top routine on the
task's stack when a rendezvous takes place?) or just not worth the
effort.  In any case, though, I still think your earlier statement,
that the rule is "necessary" to make sure that a task can accept only
its own entries, is incorrect.

And although Stephen gave an example of how some problems can be
solved by putting a shared procedure inside an ACCEPT, his example was
a fairly simple one that can't always be generalized.  Suppose you
would really like a procedure that does an ACCEPT somewhere inside a
loop; you can't just yank the ACCEPT out of the loop and put it in the
main task body without some significant reorganization of the logic.

I don't use tasks much at all, so I can't come up with a real-world
example where this restriction is an annoyance or a problem, other
than the original poster's situation.

                                      -- Adam

Re: embed accept statement in procedures not possible?

[Jean-Pierre Rosen]

Adam Beneschan a �crit :

> I don't use tasks much at all, so I can't come up with a real-world
> example where this restriction is an annoyance or a problem, other
> than the original poster's situation.
> 
Well, I've been using tasking quite a lot, and never missed that feature...

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

Re: embed accept statement in procedures not possible?

[Pascal Obry]

Jean-Pierre Rosen a �crit :
> Adam Beneschan a �crit :
> 
>> I don't use tasks much at all, so I can't come up with a real-world
>> example where this restriction is an annoyance or a problem, other
>> than the original poster's situation.
>>
> Well, I've been using tasking quite a lot, and never missed that feature...

Idem.

Pascal.

-- 

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

Re: embed accept statement in procedures not possible?

[(see below)]

On 4/5/07 16:04, in article
1178291081.936739.131740@c35g2000hsg.googlegroups.com, "Gerd"
<GerdM.O@t-online.de> wrote:

> task body t is
>   procedure p is
>   begin
>     accept e;
>   end p;
> begin
>   p;
> end t;
> 
> GNAT tells me: "enclosing body for accept must be a task". But - the
> accept in procedure p _is_ in a task. So why is this not allowed?

Because it is not legal Ada.
See Ada (2005) Reference Manual Section 9.5.1, thus:

> For an accept_statement, the innermost enclosing body shall be a task_body,

IOW, the accept must not be in a body nested within the task body,
it must be *immediately* within the task body.

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: embed accept statement in procedures not possible?

[adaworks]

"(see below)" <yaldnif.w@blueyonder.co.uk> wrote in message 
news:C26125DB.A99CF%yaldnif.w@blueyonder.co.uk...
> On 4/5/07 16:04, in article
> 1178291081.936739.131740@c35g2000hsg.googlegroups.com, "Gerd"
> <GerdM.O@t-online.de> wrote:
>
>>
>> GNAT tells me: "enclosing body for accept must be a task". But - the
>> accept in procedure p _is_ in a task. So why is this not allowed?
>
> Because it is not legal Ada.
> See Ada (2005) Reference Manual Section 9.5.1, thus:
>
Bill is correct in his reply.   However, an accept statement
is the implementation of an entry at the specification level.
And one can rename an entry into a procedure.   It is not
likely that this will help with the stated problem, but there
might be some solution lurking in that capability.

Richard Riehle 

Re: embed accept statement in procedures not possible?

[Stephen Leake]

Gerd <GerdM.O@t-online.de> writes:

> Hi all,
>
> I work with GNAT 3.15 on Windows XP. My problem is that I want
> structure my program in a way that is not accepted by GNAT, but I
> cannot understand why.
>
> My code (schematic only):
>
> task t is
>   entry e;
> end t;
>
> task body t is
>   procedure p is
>   begin
>     accept e;
>   end p;
> begin
>   p;
> end t;
>
> GNAT tells me: "enclosing body for accept must be a task". But - the
> accept in procedure p _is_ in a task. So why is this not allowed?
>
> My accept statement is a bit longer and needed a few times in
> different situations. Therefore I don't want to "copy and paste" this
> code directly in the task body.

You can make the body of the accept call a shared procedure:

task body t is
  procedure p is
  begin
    ...;
  end p;
begin
  accept e do
    p;
  end;

  ... 

  accept e do
    p;
  end;

  ...
end t;


>
>
> Gerd
>

-- 
-- Stephe