CVS difference for ai05s/ai05-0004-1.txt

--- ai05s/ai05-0004-1.txt	2006/11/10 06:44:49	1.4
+++ ai05s/ai05-0004-1.txt	2007/01/13 05:25:55	1.5
@@ -1,4 +1,5 @@
-!standard C.7.1(17/2)                               06-11-03  AI05-0004-1/02
+!standard C.7.1(17/2)                               07-01-12  AI05-0004-1/03
+!standard 1.1.4(14.1/2)
 !standard 3.8(13.1/2)
 !standard 3.10.2(12.2/2)
 !standard 4.1(7)
@@ -6,6 +7,7 @@
 !standard 7.3(10.1/2)
 !standard 9.1(9.4/2)
 !standard 10.1.3(10)
+!standard 10.1.1(17)
 !standard 12.3(7)
 !standard A.11(4/2)
 !standard D.9(6)
@@ -46,6 +48,10 @@
 11) The title of J.1 should be "Renamings of Library Units from Previous Versions
 of this Standard".
 
+12) "exponent" in 1.1.4(14.1/2) should be in the sans-serif font.
+
+13) The second sentence of 10.1.1(17) is deleted.
+
 !question
 
 1) Does C.7.1(17/2) apply to calls to Current_Task in an entry barrier? (Yes.)
@@ -81,6 +87,23 @@
 occurrence of "Ada 83" in the Standard, and given that for ISO, that standard was
 Ada 87, this looks bad. This title should be changed.
 
+12) 1.1.4(14.1/2) refers to the "definition of exponent". Does this refer to the
+syntax "exponent"? It doesn't appear to, because it is not in the syntax font.
+
+13) The second sentence of 10.1.1(17) says:
+
+  The renaming of a child of a generic package shall occur only within the
+  declarative region of the generic package.
+
+10.1.1(18) says:
+
+  A child of a parent generic package shall be instantiated or renamed only
+  within the declarative region of the parent generic.
+
+Considering just renames, these two sentences say exactly the same thing, in
+two different ways. And they are adjacent paragraphs in the Standard! Is this
+the Department of Redundancy Department? (Yes.)
+
 [Other questions here.]
 
 !recommendation
@@ -112,6 +135,10 @@
 11) The title of J.1 should be "Renamings of Library Units from Previous Versions
 of this Standard".
 
+12) "exponent" should be in the sans-serif font.
+
+13) The second sentence of 10.1.1(17) should be deleted.
+
 !discussion
 
 1) entry_barrier is syntactically within entry_body. C.7.1(17/2) however, says
@@ -152,12 +179,37 @@
 11) "Ada 83" is meaningless from a standards perspective; it should not be used in
 normative text.
 
+12) "exponent" refers to the syntax defined in 2.4.1, and should be in the syntax font.
+
 Many of these corrections were made in the Ada Europe edition
 of the consolidated reference manual. The original versions were producing linking
 errors in the HTML versions (which link syntax terms to their definitions).
 But the error is present in the 'official' documents: the final version of the Ada 95 RM,
 Corrigendum, and Amendment; so we need to fix these 'officially'.
 
+13) It would not help to have two very similar rules that are written differently.
+10.1.1(18) is the more general rule, so we remove the less general second sentence of
+10.1.1(17).
+
+!corrigendum 1.1.4(14.1/2)
+
+@drepl
+The delimiters, compound delimiters, reserved words, and @fa<numeric_literal>s
+are exclusively made of the characters whose code position is between
+16#20# and 16#7E#, inclusively. The special characters for which names
+are defined in this International Standard (see 2.1) belong to the same
+range. For example, the character E in the definition of exponent is the
+character whose name is "LATIN CAPITAL LETTER E", not "GREEK CAPITAL
+LETTER EPSILON".
+@dby
+The delimiters, compound delimiters, reserved words, and @fa<numeric_literal>s
+are exclusively made of the characters whose code position is between
+16#20# and 16#7E#, inclusively. The special characters for which names
+are defined in this International Standard (see 2.1) belong to the same
+range. For example, the character E in the definition of @fa<exponent> is the
+character whose name is "LATIN CAPITAL LETTER E", not "GREEK CAPITAL
+LETTER EPSILON".
+
 !corrigendum 3.8(13.1/2)
 
 @drepl
@@ -219,6 +271,17 @@
 in the @fa<full_type_declaration> if and only if it also appears in the
 @fa<private_extension_declaration>.
 
+!corrigendum 10.1.1(17)
+
+@drepl
+A child of a generic library package shall either be itself a generic unit or
+be a renaming of some other child of the same generic unit. The renaming of a
+child of a generic package shall occur only within the declarative region of
+the generic package.
+@dby
+A child of a generic library package shall either be itself a generic unit or
+be a renaming of some other child of the same generic unit. 
+
 !corrigendum 10.1.3(10)
 
 @drepl
@@ -466,6 +529,60 @@
 bounded error is the hope that it reduces the chance that
 implementations are forced to do something expensive but
 useless.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, December 20, 2006  7:07 PM
+
+The second sentence of 10.1.1(17) says:
+
+The renaming of a child of a generic package shall occur only within the
+declarative region of the generic package.
+
+10.1.1(18) says:
+
+A child of a parent generic package shall be instantiated or renamed only
+within the declarative region of the parent generic.
+
+Considering just renames, these two sentences seem to say exactly the same
+thing.
+
+It's pretty silly to have two rules that say exactly the same thing.
+Especially when they are in adjacent paragraphs. (The only saving grace is
+that they're on different pages in the printed version of the consolidated
+Ada 95 RM.)
+
+For what it's worth, these rules were added very late in the Ada 9X
+process - version 4.0 doesn't have them at all, version 5.0 has them with a
+different more complicated version of 10.1.1(18) that only covers instances
+(and thus isn't redundant).
+
+Anyway, presuming that I haven't missed some subtlety, what is the best fix
+here? (Removing redundant text is a presentation fix, so it is appropriate
+to consider it now, and we have a presentation AI.)
+
+(1) Remove the "or renaming" from 10.1.1(18).
+(2) Remove the second sentence of 10.1.1(17) completely.
+
+(1) is a smaller change, (2) probably is more understandable (it's weird to
+write very similar rules in very different ways).
+
+What do you think?
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, December 20, 2006  9:16 PM
+
+(2) I would eliminate the separate sentence about renaming completely.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Thursday, December 21, 2006  1:29 AM
+
+Vote for (2).
 
 ****************************************************************