CVS difference for ais/ai-00114.txt

Differences between 1.16 and version 1.17
Log of other versions for file ais/ai-00114.txt

--- ais/ai-00114.txt	2006/05/12 20:28:25	1.16
+++ ais/ai-00114.txt	2006/11/13 06:31:37	1.17
@@ -1104,8 +1104,161 @@
+!topic Which library items are "mentioned"?
+!reference 10.1.2(6)
+!from Adam Beneschan 06-08-08
+10.1.2(6/2) says:
+    A library_item (and the corresponding library unit) is named in a
+    with_clause if it is denoted by a library_unit_name in the
+    with_clause. A library_item (and the corresponding library unit)
+    is mentioned in a with_clause if it is named in the with_clause or
+    if it is denoted by a prefix in the with_clause.
+And, in the AARM, 10.1.2(6.b) says:
+    Note that this rule implies that "with A.B.C;" is equivalent to
+    "with A, A.B, A.B.C;".
+But it seems to me that this rule does *not* imply that.  The reason
+is:  The units in a WITH clause have the syntax of a "name".  The
+syntax of a "name" is defined in 4.1(2); this syntax includes things
+like "expliict_dereference", "type_conversion", etc., but the only
+ones that apply here are "direct_name" and "selected_component".  A
+direct_name is just a simple identifier, so it doesn't apply here.
+The syntax of a "selected_component" is (4.1.3(2)):
+    prefix . selector_name
+where a selector_name is an identifier (or a character literal or
+operator symbol, which don't apply here).  Since a selector name must
+be a simple identifier, then in the clause
+    with A.B.C;
+the only possible "prefix" is A.B, which means that A.B is mentioned
+by the WITH clause but A is not.
+I haven't yet figured out whether this has any significance in terms
+of visibility.  Nevertheless, this appears to be clearly wrong.  The
+RM apparently is using "prefix" in a loose sense, where A, A.B, A.B.C,
+A.B.C.D, etc., are all considered "prefixes" of A.B.C.D.E.F.G.H.I.J.
+But nothing in the RM supports any definition of "prefix" that would
+make this true.  I'd suggest that the term "prefix" in 10.1.2(6)
+[which is in a font that implies that it refers to the actual
+syntactic definition of "prefix" in 4.1] with a different term that
+would make all of the ancestors prefixes.
+From: Adam Beneschan
+Sent: Tuesday, August 8, 2006  6:00 PM
+> I haven't yet figured out whether this has any significance in terms
+> of visibility.
+OK, I think I figured it out.  10.1.2(7) says that a library unit can
+be visible only within the scope of a with_clause that mentions it.
+Thus, if "with A.B.C;" causes A.B, but not A, to be "mentioned", this
+means that something that with's A.B.C can't refer to A or to anything
+declared in A (except for the child unit A.B).  So yes, the apparent
+error in 10.1.2(6) makes a big difference as to what declarations are
+From: Tucker Taft
+Sent: Tuesday, August 8, 2006  6:07 PM
+I think you are partly right, but for a different reason.
+The AARM note seems to be left over from Ada 95, because
+in Ada 2005, the notion of being "named" in a with clause
+is new, and given "with A.B.C;", "A.B.C" is "named"
+(*and* "mentioned"), while "A" and "A.B" are only "mentioned."
+So "with A, A.B, A.B.C;" is *not* strictly equivalent to
+"with A.B.C;" in terms of these definitions.  It makes
+a difference for "limited" with clauses, because a unit
+that is *named* in a limited with clause may not be
+the same as a unit that is *mentioned" in a with clause for
+the same compilation unit.
+But you are actually complaining about the use of the phrase
+"prefix in the with_clause" but I believe that is fine.
+Note that it says "in" not "of" the with_clause.
+Since it says "in" then higher level syntactic categories
+are expanded "all the way down" in pursuit of the specified
+syntactic category.  For "A.B.C" we have the parse tree
+           name
+          /    \
+    prefix  .  selector
+       |
+      name
+      /   \
+  prefix . selector
+meaning that both "A" and "A.B" are prefixes "in"
+the with_clause
+From: Pascal Leroy
+Sent: Wednesday, October 11, 2006  9:47 AM
+Since you are in the mode of fixing typos, 3.9.2(24.j/2) has:
+"An stream attribute of a tagged type is is usually"
+An should be a and is is should be is.
+From: Randy Brukardt
+Date: October 13, 2006
+3.1(11.i) says that an "entry_list_iterator" is evaluable. What the heck
+is that? Probably "entry_index_specification" was meant.
+3.11(14.a) says that "variable_declaration"s can be used; but that doesn't
+exist. It should say "object_declaration".
+4.1(3.a) talks about a "enumeration_type_declaration" being visible. But there
+is no such thing, and definitions (what does exist) don't have visibility
+per se. So this should be regular text as "enumeration type declaration".
+8.1(11.b) talks about a "derived_type_declaration"; but there is no such
+syntax; "derived_type_definition" should be used instead.
+8.6(34.l) seems to have missed the Corrigendum change from
+"representation_clause" to "aspect_clause".
+11.2(12.b) says "choice" (which is not defined) when "exception_choice" is
+12.3(11.a) talks about an "extension_part"; this is properly called a
+12.3(15.c) talks about "formal_parameter_specifications"; but these are
+simply called "parameter_specifications".
+12.3(29.e) talks about a "generic_formal_parameter" as syntax; but the
+syntax isn't appropriate here.
+13.3(86.c) seems to have missed the Corrigendum change from
+"representation_clause" to "aspect_clause".
+13.14(11.a) uses "deferred_constant_declaration"; but this is not
+defined syntactically.
+13.14(20.o) uses "attribute_representation_clause", but this is
+actually known as an "attribute_definition_clause".
 From: Randy Brukardt (Editor)
-Date: May 15, 2006
+Date: October 16, 2006
 I've made the corrections needed to implement the presentation issues
 above in the final updated AARM (Amendment 1 version), or explained why the

Questions? Ask the ACAA Technical Agent