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

Differences between 1.27 and version 1.28
Log of other versions for file ai05s/ai05-0183-1.txt

--- ai05s/ai05-0183-1.txt	2011/04/30 07:28:36	1.27
+++ ai05s/ai05-0183-1.txt	2011/06/20 04:55:18	1.28
@@ -44,6 +44,7 @@
 !standard 13.14(8/2)
 !class amendment 09-11-01
 !status Amendment 2012 10-09-01
+!status ARG Approved (by Letter Ballot) 10-1-0  11-05-16
 !status work item 10-11-19
 !status ARG Approved  8-0-2  10-10-29
 !status work item 09-11-01
@@ -372,7 +373,7 @@
   [type of the subtype]{entity} denoted by the local_name{, except in
   the case of a type-related operational item, whose local_name shall
   denote a first subtype, and which directly specifies an aspect of the
-  type of the subtype. [The local_name of an operational item shall
+  type of the subtype.} [The local_name of an operational item shall
   denote a first subtype. An operational item that names a subtype is
   type-related.]
 
@@ -575,7 +576,7 @@
 
     * An aspect specified on a renaming_declaration.
 
-  Other aspect_specifications are associated with the entity, and apply
+  All other aspect_specifications are associated with the entity, and apply
   to all views of the entity, unless otherwise specified in this
   International Standard.
 
@@ -616,7 +617,7 @@
     the private type is not considered an indexable type.
 
   There are no language-defined aspects that may be specified on a
-  renaming_declaration nor on a formal_type_declaration.
+  renaming_declaration or on a formal_type_declaration.
 
     AARM Discussion: Implementation-defined aspects can be allowed on these, of
     course; the implementation will need to define the semantics. In particular,
@@ -1412,8 +1413,8 @@
 
 @xbullet<An aspect specified on a @fa<renaming_declaration>.>
 
-Other @fa<aspect_specification>s are associated with the entity, and apply
-to all views of the entity, unless otherwise specified in this
+All other @fa<aspect_specification>s are associated with the entity, and
+apply to all views of the entity, unless otherwise specified in this
 International Standard.>
 
 If the @fa<aspect_mark> includes 'Class, then:
@@ -1446,7 +1447,7 @@
 is visible (see 8.3) at the point of the application of the rule.
 
 There are no language-defined aspects that may be specified on a
-@fa<renaming_declaration> nor on a @fa<formal_type_declaration>.
+@fa<renaming_declaration> or on a @fa<formal_type_declaration>.
 
 An aspect shall not be specified in an @fa<aspect_specification> given on a
 @fa<subprogram_body> that is a completion of another declaration.
@@ -6747,5 +6748,211 @@
 
 I don't know whther the !discussion is up for chnage as well but it ought to
 be mentioned there as well. And maybe the business about subprogram bodies.
+
+****************************************************************                                                                                                                                                                                               
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                     implementing semantic features.
+
+From: Tucker Taft
+Sent: Monday, May 2, 2011  9:44 PM
+
+[Appropriate part of a large message - Editor.]
+
+AI05-0183-1/14  Aspect specifications
+    [Changes from phone meeting: removed Address aspect as a special case.
+     Changes from Bob's editorial review.]
+    Approve ___X___ Disapprove ______ Abstain _______
+   Comments:  This paragraph could use a bit of editorial improvement,
+    by substituting "identify" or "define" or almost anything instead
+    of "specify," especially in the third sentence:
+     All specifiable operational and representation attributes may be
+     specified with an aspect_specification instead of an
+     attribute_definition_clause (see 13.3). The attribute_designator is
+     used for the aspect_mark. In addition, certain other operational and
+     representation aspects not associated with specifiable attributes may
+     be specified, as specified elsewhere in this International Standard.
+     In the case of aspects specifiable with pragmas, the pragma identifier
+     is used for the aspect_mark, unless otherwise specified in this International
+     Standard.
+
+    The department of redundancy department loves this sentence (one of the
+    "attributes" needs to go) in 13.13.2:
+      The {type-related} operational attributes Write, Read, Output, and
+      Input attributes convert values to a stream of elements and
+      reconstruct values from a stream.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, May 2, 2011  10:32 PM
+
+[Appropriate part of a larger message - Editor.]
+
+> AI05-0183-1/14  Aspect specifications
+>     [Changes from phone meeting: removed Address aspect as a special case.
+>      Changes from Bob's editorial review.]
+>     Approve ___X___ Disapprove ______ Abstain _______
+>    Comments:  This paragraph could use a bit of editorial improvement,
+>     by substituting "identify" or "define" or almost anything instead
+>     of "specify," especially in the third sentence:
+>      All specifiable operational and representation attributes may be
+>      specified with an aspect_specification instead of an
+>      attribute_definition_clause (see 13.3). The attribute_designator is
+>      used for the aspect_mark. In addition, certain other operational and
+>      representation aspects not associated with specifiable attributes may
+>      be specified, as specified elsewhere in this International Standard.
+>      In the case of aspects specifiable with pragmas, the pragma identifier
+>      is used for the aspect_mark, unless otherwise specified in this International
+>      Standard.
+
+Unfortunately, "specify" here is a technical term, so I don't think we can change it
+to something else. 13.3 uses "specifiable attribute" and "attribute_definition_clause
+that specifies", and those are the terms that we are trying to (re)define here.
+"unless otherwise specified" is pretty standard boilerplate (I found at least 8 other
+references to it in the current RM).
+
+So there is only one use of "specify" in the whole paragraph that we could even consider
+changing, the one in the third sentence.
+
+"In addition, certain other operational and representation aspects not associated with
+specifiable attributes may be *specified*, as specified elsewhere in this International
+Standard."
+
+But it is odd to use another term here, as this is an "aspect_specification", not an
+"aspect_definition" or an "aspect_identification".
+
+So I don't think there is much that we can do with this one, unless someone has a
+substitute for "unless otherwise specified".
+
+>     The department of redundancy department loves this sentence (one of the
+>     "attributes" needs to go) in 13.13.2:
+>       The {type-related} operational attributes Write, Read, Output, and
+>       Input attributes convert values to a stream of elements and
+>       reconstruct values from a stream.
+
+The last one is deleted text picked up by cut-and-paste from the HTML RM.
+
+****************************************************************                                                                                                                                                                                               
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                     implementing semantic features.
+
+From: Erhard Ploedereder
+Sent: Sunday, May 15, 2011 at 11:31 AM
+
+[The appropriate part of a longer message - Editor.]
+
+AI05-0183-1/14  Aspect specifications
+   [Changes from phone meeting: removed Address aspect as a special case.
+    Changes from Bob's editorial review.]
+   Approve ______ Disapprove ___X___ Abstain _______
+
+======================
+
+Editorials:
+
+> Modify 13.1(8.1/1) as follows:
+
+the para. lacks a "}"
+
+> Other aspect_specifications are associated with the entity, and apply
+> to all views of the entity, unless otherwise specified in this
+> International Standard.
+
+Change to: "All other ..."
+
+> There are no language-defined aspects that may be specified on a
+> renaming_declaration nor on a formal_type_declaration.
+
+"nor" -"or" by my English teacher, since it is not the "specified"
+that is negated. "may be specified neither on .. nor on..." would be the correct
+use of "nor".
+
+
+Technical concerns:
+
+> In the case of aspects specifiable with pragmas, the pragma identifier
+> is used for the aspect_mark, unless otherwise specified in this International
+>   Standard.
+
+Is it really intended that implementation-defined pragmas are unconditionally
+restricted to abide by this rule? (Probably not.)
+
+
+> Alternative legality and semantics rules may apply for particular
+> aspects, as specified elsewhere in this International Standard.
+
+"Additional" I'll buy any day, but "Alternative" rules in unspecified places are
+a completely bogus way of describing a language.
+
+****************************************************************                                                                                                                                                                                               
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                     implementing semantic features.
+
+From: Randy Brukardt
+Sent: Tuesday, May 17, 2011 at  2:08 AM
+
+...
+> AI05-0183-1/14  Aspect specifications
+>    [Changes from phone meeting: removed Address aspect as a special case.
+>     Changes from Bob's editorial review.]
+>    Approve ______ Disapprove ___X___ Abstain _______
+>
+> ======================
+>
+> Editorials:
+>
+> > Modify 13.1(8.1/1) as follows:
+>
+> the para. lacks a "}"
+
+Got it.
+
+> > Other aspect_specifications are associated with the entity, and
+> > apply to all views of the entity, unless otherwise specified in this
+> > International Standard.
+>
+> Change to: "All other ..."
+
+OK.
+
+> > There are no language-defined aspects that may be specified on a
+> > renaming_declaration nor on a formal_type_declaration.
+>
+> "nor" -"or" by my English teacher, since it is not the "specified"
+> that is negated. "may be specified neither on .. nor on..."
+> would be the correct use of "nor".
+
+I think you are right.
+
+>
+> Technical concerns:
+>
+> > In the case of aspects specifiable with pragmas, the pragma
+> > identifier is used for the aspect_mark, unless otherwise specified in this International
+> >   Standard.
+>
+> Is it really intended that implementation-defined pragmas are
+> unconditionally restricted to abide by this rule? (Probably not.)
+
+I don't think anything mentioned in the Standard could really affect
+implementation-defined anythings, especially in a case like this.
+
+But I don't see a better way to say this, short of dropping the "in this
+International Standard" part. And I believe we originally had the wording that
+way and others complained. So I won't make a change here until/unless a better
+alternative emerges.
+
+> > Alternative legality and semantics rules may apply for particular
+> > aspects, as specified elsewhere in this International Standard.
+>
+> "Additional" I'll buy any day, but "Alternative" rules in unspecified
+> places are a completely bogus way of describing a language.
+
+Maybe, but otherwise we would not be able to define "default" rules for
+processing aspects (which is what these are). But the default rules need to be
+able to be overridden in various places. For example, the rules about boolean
+aspects are explictly overridden for Default_Value when it happens to be
+boolean. The alternatives are not good: either duplicating rules everywhere (I
+hope not), or defining many additional classes of aspects and then repeating all
+of the rules for each. (That potentially would include repeating the rules of
+13.1, since those too are overridden sometimes with "alternative" rules.)
+
+If you have a proposal for dealing with this that does not require "alternative"
+rules, please make it, but in the absence of some sort of concrete proposal I
+don't think that I can do anything with this comment.
 
 ****************************************************************                                                                                                                                                                                               
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                     implementing semantic features.

Questions? Ask the ACAA Technical Agent