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

--- ai05s/ai05-0009-1.txt	2008/08/08 05:21:31	1.8
+++ ai05s/ai05-0009-1.txt	2008/10/25 04:53:13	1.9
@@ -1,4 +1,4 @@
-!standard 9.10(1)                                      08-07-08    AI05-0009-1/06
+!standard 9.10(1)                                      08-10-22    AI05-0009-1/07
 !standard 13.1(15/1)
 !standard 13.2(9)
 !standard 13.3(13)
@@ -7,7 +7,9 @@
 !standard C.6(6)
 !standard C.6(9)
 !standard C.6(13)
+!standard C.6(14)
 !class binding interpretation 06-03-21
+!status work item 08-10-10
 !status ARG Approved  8-0-0  08-06-21
 !status work item 06-03-21
 !status received 06-02-20
@@ -34,7 +36,7 @@
 which is still considered non-confirming.
 
 Execution is erroneous if an address clause specifies a valid address
-that is not appropriate for the entity or its use.
+that is not appropriate for either the entity or its use.
 
 !question
 
@@ -94,7 +96,8 @@
 representation is overridden by a subsequent representation item that
 specifies {a different value for} the same aspect of the type or subtype. 
 
-AARM Ramification: If an inherited aspect is confirmed by a later representation
+AARM Ramification: If an inherited non-confirming aspect is confirmed by
+a later representation
 item for a derived type, the confirming representation item does not override
 the inherited one. Thus the derived type has both a specified confirming and
 an inherited non-confirming representation item -- this means that rules
@@ -103,11 +106,11 @@
 
 Change 13.2(9) as follows:
 
-* For a packed array type, if the component subtype's Size is less than
-  or equal to the word size, [and Component_Size is not specified for
-  the type,] Component_Size should be less than or equal to the Size
-  of the component subtype, rounded up to the nearest factor of the
-  word size.
+* For a packed array type, if the [component subtype's] Size {of the
+  component subtype} is less than or equal to the word size, [and
+  Component_Size is not specified for the type,] Component_Size should
+  be less than or equal to the Size of the component subtype, rounded
+  up to the nearest factor of the word size.
 
 
 Change 13.3(13) as follows:
@@ -139,7 +142,7 @@
 pragma Independent_Components(local_name);
 
 
-Change C.6(9) as follows: [Name Resolution]
+Change C.6(9) as follows: [Name Resolution Rules]
 
 The local_name in an Atomic or Volatile pragma shall resolve
 to denote either an object_declaration, a non-inherited component_declaration,
@@ -164,6 +167,14 @@
 prevents the implementation from providing the independent addressability required
 by the pragma.
 
+Add after C.6(14): [Static Semantics]
+
+Pragmas Independent and Independent_Components guarantee independent addressability
+for the named object or component, or in the case of a type, for objects of that type
+(see 9.10).
+
+[This is marked redundant in the AARM.]
+
 !discussion
 
 The problem to be addressed is demonstrated by the following (on a
@@ -210,7 +221,7 @@
 Introduces the new pragmas, defining Independent to be applicable to
 individual record components, and Independent_Components which
 applies to array and record types.
-Pragma independent and Independent_Components are similar to Volatile and
+Pragma Independent and Independent_Components are similar to Volatile and
 Atomic in that only a single entity name is accepted with the pragma.
 
 The minutes from Albuquerque note that pragma Independent_Components
@@ -220,13 +231,16 @@
 as a representation pragma, it is not allowed on partial views
 (by 13.1(9)), so we only need to allow array and record types.
 
+We add redundant wording in C.6(14) so that the new pragmas have some
+description of their semantics in C.6 (otherwise, their meaning is
+mysterious).
 
 
 A separate problem was identified during the preparation of this AI.
 A confirming representation item specifies the value that the compiler
 would have chosen anyway. However, a derived type can inherit a
 non-confirming representation value; if this value is then specified,
-we want to be remain non-confirming.
+we want it to remain non-confirming.
 
 We also noted that 13.2(9) seems to allow different behavior if a
 confirming representation clause is given, which breaks the model that
@@ -234,7 +248,7 @@
 
 It was also noted that an address specified in an address clause could
 be used to break independent addressibility in places where it was
-required. 13.3(13) could cover this by using a expansive reading of
+required. 13.3(13) could cover this by using an expansive reading of
 "valid" (where an address isn't valid if it causes some violation of
 semantics even if it is legitimate address for the target), but
 hardly anyone [Editor's note: except Tucker! ;-)] reads this paragraph
@@ -298,13 +312,13 @@
 
 @drepl
 @xbullet<For a packed array type, if the component subtype's Size is less than
-or equal to the word size, [and Component_Size is not specified for
-the type,] Component_Size should be less than or equal to the Size
+or equal to the word size, and Component_Size is not specified for
+the type, Component_Size should be less than or equal to the Size
 of the component subtype, rounded up to the nearest factor of the
 word size.>
 @dby
-@xbullet<For a packed array type, if the component subtype's Size is less than
-or equal to the word size, Component_Size should be less than or equal to the
+@xbullet<For a packed array type, if the Size of the component subtype is less
+than or equal to the word size, Component_Size should be less than or equal to the
 Size of the component subtype, rounded up to the nearest factor of the
 word size.>
 
@@ -2481,5 +2495,86 @@
 Although not previously noted, the lead-in paragraph (C.6(2)) to the syntax
 of the pragmas needs to be updated as well.
 
+****************************************************************
+
+Editor's note, Wednesday, October 22, 2008
+
+During editorial review of this AI, Pascal Leroy objected to the organization of
+the wording by this AI. Here is an edited summary of the discussion on that
+topic between Pascal Leroy, Ed Schonberg, and Randy Brukardt.
+
+Pascal:
+I find the overall structure of this AI quite strange: the syntax and legality
+of the new pragmas are defined in C.6, but the actual semantics are hidden in
+9.10(1).  Even worse, for atomicity, a bit of the semantics (the independence)
+is also hidden in 9.10(1).  It would have been nicer to define the full semantics
+in C.6 (for instance by saying that the pragmas make the object "potentially
+independently addressable", or some other technical term) and use that term
+in 9.10.
+
+Ed:
+Note that 9.10 already has references to Annex C, in particular 9.10 (15), so
+maybe the pragmas should be mentioned first at the end of 9.10? 
+
+Pascal:
+I actually think that it would be fine to have a forward reference similar to
+9.10(15): "A pragma Independent may also be used to ensure that certain objects
+are independently addressible".  But I have a problem with the fact that, as the
+AI stands today, the new text in C.6 doesn't say a word about the semantics of
+the pragma.  To the reader of this annex, this is going to be entirely mysterious.
+
+Randy:
+The 9.10 text has a number of forward references to C.6. But the idea of putting
+the entire definition in C.6 would make a much more massive forward reference
+where no significant one exists today. Moreover, we originally had a proposal
+for a term like "independent addressable object", and it was removed during a
+meeting to simplify the presentation. To put it back is completely wrong.
+ 
+I think that all that is really needed is a user note to point to 9.10 for the
+semantics for pragma Independent.
+
+Pascal:
+It reads very weird in C.6: the Dynamic Semantics and Implementation Requirements
+section don't mention pragmas Independent... at all. That's plain wrong. The
+solution adopted for pragma Atomic (where the pragma is fully defined in C.6
+with a forward reference in 9.10) seems much preferable. I don't care that this
+would add a forward reference, it just doesn't make sense to have a pragma
+defined in two places.
+
+Ed:
+I tend to agree, the pragmas should be treated in the same way.
+
+Randy:
+We now have a major problem, as I am the author of record on this AI, and I
+totally disagree with both of you on this one. This could very well kill the AI
+in my opinion, or worse make it completely impenetrable and full of bugs.
+ 
+(1) Pascal's original suggest of defining a term like "independent object" was
+tried in an earlier version of the AI, and it doesn't work. The problem is that
+independence is always between *two* objects; there is no such thing as a single
+object being independent. The only way that we could find that made sense was to
+eliminate the term.
+ 
+(2) The definition of independence in 9.10 is very intertwined with the meaning
+of the pragmas. I tried factoring them out or inverting the definition, and it
+simply does not work. Tucker suggested the current formulation, but it still took
+5 or 6 tries to get it right.
+ 
+(3) Moving the definition of independence to Annex C makes no sense; this is a
+core definition that has no bearing on the pragmas.
+ 
+(4) I think the pragmas should be defined in 9.10 (they ought to be a core feature
+supported by all implementations), but I lost that battle previously. Someone thought
+that they were similar to the existing pragmas in C.6, but it turns out that they
+are not at all similar. However, I don't want to be reopening previous decisions
+in the absence of a clear error -- which we do not have here.
+ 
+As such, the only thing I could see doing here would be to add a redundant
+paragraph in C.6 under Static Semantics
+ 
+[Pragmas Independent and Independent_Components guarantee independent addressability
+for the named object or component, or in the case of a type, for objects of that
+type (see 9.10).]
+ 
 ****************************************************************