Visibility of accept statements AI-00593/00 1 88-10-05 BI RE !standard 04.01.03 (17) 88-10-05 AI-00593/00 !class binding interpretation 88-10-05 !status received 88-10-05 !topic Visibility of accept statements !summary 88-10-05 !question 88-10-05 !recommendation 88-10-05 !discussion 88-10-05 !appendix 87-08-19 ***************************************************************************** !section 04.01.03 (17) J. Goodenough 87-08-19 83-00941 !version 1983 !topic Visibility of accept statements 4.1.3(17-19) say for expanded names within accept statements: The prefix must denote a construct that is either a program unit, a block statement, a loop statement, or an accept statement. In the case of an accept statement, the prefix must be either the simple name of the entry or entry family, or an expanded name ending with such a simple name (that is no index is allowed). ... ... If the prefix is the name of a subprogram or accept statement and if there is more than one visible enclosing subprogram or accept statement of this name, the expanded name is ambiguous, independently of the selector. If, according to the visibility rules, there is at least one possible interpretation of the prefix of a selected component as the name of an enclosing subprogram or accept statement, then the only interpretations considered are those of rule (f) as expanded names (no interpretations of the prefix as a function call are then considered). These paragraphs talk as though accept statements can be named as denoted entities, but accept statements are not mentioned in the list of declared entities (see 3.1(1)), nor are accept statements declared. The visibility rules associate identifiers with declarations, so, strictly speaking, it is unclear what the Standard means when it speaks of a name that "denotes" an accept statement or even the name "of" an accept statement. What is the intent here? What does it mean for an accept statement to be "visible" when it is not declared? Note that 8.3(2) says: The visibility rules determine a set of declarations [for an identifier] that define possible meanings of an occurrence of Visibility of accept statements AI-00593/00 2 88-10-05 BI RE the identifier. A declaration is said to be visible at a given place in the text when, according to the visibility rules, the declaration defines a posible meaning of this occurrence. In these terms, an accept statement is never visible since it is never declared. In considering this issue, note that the declarative region for an entry includes the accept statements for the entry. Also, consider the following examples: task T is entry SINGLE(X : INTEGER); entry FAMILY(BOOLEAN)(Y : INTEGER); end T; task body T is begin accept SINGLE(X : INTEGER) do declare function SINGLE return INTEGER is Y : INTEGER; begin SINGLE.Y := X; -- illegal At the point of the assignment statement, it is clear that two declarations of SINGLE are visible -- one within the declarative region associated with the entry declaration and accept statement, and the other within the region associated with the function body. SINGLE.Y is clearly an expanded name since SINGLE can be interpreted as the name of an enclosing subprogram [4.1.3(19)]. Now we come to 4.1.3(18): If the prefix [of an expanded name] is the name of a subprogram or accept statement and if there is more than one visible enclosing subprogram or accept statement of this name, the expanded name is ambiguous, independently of the selector. "The name of an accept statement" is not a technically meaningful phrase, but given the context, the intent is clear: presumably it means "the entry or entry family name given in an accept statement", and the visibility rules do apply to these names. In the above example, there is an enclosing accept statement associated with the single entry SINGLE, and an enclosing function named SINGLE. The visibility rules say that both the entry and the subprogram are visible at the point of the assignment statement, so the rule in paragraph 18 means that SINGLE.Y is illegal. Now consider a similar example with the entry family: accept FAMILY(TRUE)(Y : INTEGER) do declare function FAMILY return INTEGER is Z : INTEGER; begin FAMILY.Z := Y; -- legal Visibility of accept statements AI-00593/00 3 88-10-05 BI RE Presumably this is okay because the normal visibility rules make only the function FAMILY visible at the assignment statement since entry families are not overloadable. In this case, one could say the enclosing accept statement is not visible, but presumably such a phrase must be understood as saying that the entry or entry family given in the enclosing accept statement is not visible.