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=-0.9 required=5.0 tests=BAYES_00,FROM_NUMERIC_TLD
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,45d937e5cf2567
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news3.google.com!news.glorb.com!news.kjsl.com!news-peer-lilac.gradwell.net!not-for-mail
From: "Stuart" <stuart@0.0>
Newsgroups: comp.lang.ada
References: <4hn8k3FdjobU1@individual.net>
Subject: Re: entries and access parameters
Date: Thu, 13 Jul 2006 18:45:16 +0100
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Message-ID: <44b683f3$1_1@glkas0286.greenlnk.net>
X-Original-NNTP-Posting-Host: glkas0286.greenlnk.net
NNTP-Posting-Host: 20.133.0.1
X-Trace: 1152812723 news.gradwell.net 780 dnews/20.133.0.1:58271
X-Complaints-To: news-abuse@gradwell.net
Xref: g2news2.google.com comp.lang.ada:5665
Date: 2006-07-13T18:45:16+01:00
List-Id: <comp.lang.ada>

"Alex R. Mosteo" <devnull@mailinator.com> wrote in message 
news:4hn8k3FdjobU1@individual.net...
> I'm trying to find in the 95 rationale the explanation for this point
>
> http://www.adahome.com/rm95/rm9x-09-05-02.html
>
> (13) An entry_declaration in a task declaration shall not contain a
> specification for an access parameter (See 3.10)
> I'm curious about that prohibition, mainly to know if workarounding it 
> with
> a type like

I can't help with the reference to 3.10, but the annotated ARM gives the 
following after 9.5.2 (13)

<quote>
Reason: Access parameters for task entries would require a complex 
implementation. For example:

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

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;

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.

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).
</quote>
-- 
Stuart