From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,e1c47fd1b76b1c05
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news3.google.com!newsfeed2.dallas1.level3.net!news.level3.com!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail
From: Robert A Duff <bobduff@shell01.TheWorld.com>
Newsgroups: comp.lang.ada
Subject: Re: Task entries and access to subprograms.
Date: 07 Apr 2005 10:01:35 -0400
Organization: The World Public Access UNIX, Brookline, MA
Message-ID: <wccd5t64reo.fsf@shell01.TheWorld.com>
References: <4253B917.5070800@mailinator.com>
 <sz05e.2222$yq6.1165@newsread3.news.pas.earthlink.net>
 <4254E00C.30908@mailinator.com>
NNTP-Posting-Host: shell01.theworld.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: pcls4.std.com 1112882495 30486 192.74.137.71 (7 Apr 2005 14:01:35
 GMT)
X-Complaints-To: abuse@TheWorld.com
NNTP-Posting-Date: Thu, 7 Apr 2005 14:01:35 +0000 (UTC)
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
Xref: g2news1.google.com comp.lang.ada:10314
Date: 2005-04-07T10:01:35-04:00
List-Id: <comp.lang.ada>

"Alex R. Mosteo" <devnull@mailinator.com> writes:

> I see reading the rationale that here the prohibition is more of a
> convenience for the compiler writers than a true restriction for users.

AARM-9.5.2 explains the reason for the rule.  I'd say "convenience" is
an understatement.  ;-)

13    An entry_declaration in a task declaration shall not contain a
specification for an access parameter (see 3.10).

    13.a Reason: Access parameters for task entries would require a
          complex implementation. For example:

    13.b  task T is
             entry E(Z : access Integer); -- Illegal!
          end T;

    13.c  task body T is
          begin
             declare
                type A is access all Integer;
                X : A;
                Int : aliased Integer;
                task Inner;
                task body Inner is
                begin
                   T.E(Int'Access);
                end Inner;
             begin
                accept E(Z : access Integer) do
                   X := A(Z); -- Accessibility_Check
                end E;
             end;
          end T;

    13.d Implementing the Accessibility_Check inside the
       accept_statement for E is difficult, since one does not know
       whether the entry caller is calling from inside the immediately
       enclosing declare block or from outside it. This means that the
       lexical nesting level associated with the designated object is
       not sufficient to determine whether the Accessibility_Check
       should pass or fail.

    13.e Note that such problems do not arise with protected entries,
       because entry_bodies are always nested immediately within the
       protected_body; they cannot be further nested as can
       accept_statements, nor can they be called from within the
       protected_body (since no entry calls are permitted inside a
       protected_body).

I don't see any reasonable alternative rule, other than to forbid those
pesky nested accept statements, which was not an option because that was
already allowed in Ada 83.

- Bob