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.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!SIERRA.STANFORD.EDU!Bryan
From: Bryan@SIERRA.STANFORD.EDU (Doug Bryan)
Newsgroups: comp.lang.ada
Subject: nested accepts ?
Message-ID: <12301096303.22.BRYAN@Sierra.Stanford.EDU>
Date: Sat, 9-May-87 19:00:08 EDT
Article-I.D.: Sierra.12301096303.22.BRYAN
Posted: Sat May  9 19:00:08 1987
Date-Received: Sun, 10-May-87 08:42:08 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
List-Id: <comp.lang.ada>


[ this is a retransmission of an earlier message for which I never received
  an echo... thus, some nets may get this twice, sorry. doug ]

Dear Ada Fans,

Consider:

	task T is
	   entry A;
	   entry B;
	end T;

then within the body of T, the following is valid,

	accept A do
	   accept B;
	end A;

but NOT:

	accept A do
	   accept A;		-- illegal: RM 9.5(8)
	end A;

Does anyone know why?  What is the rationale for this restriction?
We have checked the draft of the Rationale, RM, Barnes, Cohen,
"Evaluating Ada", the Compiler Implementor's Guide, Language
Maintenance Committee Notes, *and* Booch.  Did we miss something?

We have discussed this internally within our group here at Stanford
and some possible explanations follow.

David Rosenblum has suggested that:

   "There must be a very subtle rationale for the rule disallowing
    nested accepts for the same entry or entry family.  It may be
    a ramification of other rules.  E.g., 8.1:3 says that a single
    declarative region is formed by the text of an entry declaration
    together with the corresponding accept statements.  I.e., individual
    accept statements are only part of a declarative region and do
    not by themselves form a single declarative region.  Nested
    accepts for the same entry would in effect introduce multiple declarations,
    i.e. homographs, of the same formal parameter names, within
    the same declarative region; this is disallowed by 8.3:17.  Allowing
    nesting in the case of parameterless entries would be a messy
    special case."

David Luckham has suggested that:

   "There is no attempt in any book, or the incomplete rationale to explain it.
    One possibility, is that
	accept E1 do
	    accept E1;
	end E1;
    messes up the FIFO discipline for accepting calls, since the later (inner
    accept) releases a later caller before an earlier one."

Any more clues would be appreciated.

doug and geoff
-------