Re: embed accept statement in procedures not possible?

[Adam Beneschan <adam@irvine.com>]

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