CVS difference for ai05s/ai05-0269-1.txt
--- ai05s/ai05-0269-1.txt 2012/02/10 08:17:57 1.7
+++ ai05s/ai05-0269-1.txt 2012/02/19 04:54:05 1.8
@@ -1,4 +1,4 @@
-!standard 3.2.4(0) 12-02-09 AI05-0269-1/07
+!standard 3.2.4(0) 12-02-15 AI05-0269-1/09
!standard 3.5(56/2)
!standard 3.10.1(13)
!standard 4.1.5(0)
@@ -9,7 +9,9 @@
!standard 4.5.2(30.2/2)
!standard 4.5.7(0)
!standard 4.8(3/1)
+!standard 4.9(11)
!standard 4.9(33)
+!standard 5.5.2(0)
!standard 6.1.1(0)
!standard 7.3(15)
!standard 7.3.1(5/1)
@@ -22,6 +24,7 @@
!standard 13.11(21)
!standard 13.11.3(5)
!standard 13.11.4(0)
+!standard 13.12(7/2)
!standard 13.13.2(26)
!standard A.3.5(0)
!standard A.4.11(0)
@@ -53,6 +56,8 @@
!standard D.14(11/2)
!standard D.16.1(0)
!standard E.2(5)
+!standard E.2(6)
+!standard E.2.2(14/2)
!class Amendment 11-11-09
!status Amendment 2012 12-01-12
!status work item 11-11-09
@@ -211,6 +216,39 @@
(49) 7.3.1(14-18/3) is awkward because of the partial sentence at the end. Can this be improved?
[Canada informal comment]
+(50) Predicate static should allow "and then" and "or else"; otherwise organizations with coding
+standards that require these will have to make a special exception for static predicates.
+
+(51) There should be an implementation permission for implementation-defined
+Profiles; and the permission for Restrictions should be worded consistently
+with that for pragmas.
+
+(52) In 4.1.5(2/3), "name" should be in the syntax font.
+
+(53) In 5.5.2(7/3), "iterator cursor subtype" should be "iteration cursor subtype", as this is the
+term defined in 5.5.1.
+
+(54) 1(2) gives a list of the most important of the standard package. This list should mention
+the containers, as these are argubly the most important of the packages. This is especially odd
+given that the Introduction does mention these in the equivalent list (see paragraph 42.1/2).
+
+(55) In D.16.1, the package needs a "with" of Ada.Task_Identification, and references on each
+use of an entity from that package. [Canada NB]
+
+(56) In E.2.2(14.1/3), the bullet should end with a cross-reference "(see 9.5)", as several other
+similar bullets in the area have such cross-references for unfamiliar terms. [Canada NB]
+
+(57) In A.4.11, paragraph 50/3 should come before 49/3 - describe input first then output for
+the Encode and Convert functions, like the Decode functions (51/3). [Canada NB]
+
+(58) A.16.1(28/3) should include "(including directories and special files)", as the text
+appears in A.16.1(32/3) and a number of places in A.16, so it seems it should be here as well.
+[Canada NB]
+
+(59) Add an array iteration example to 5.5.2. [Canada NB]
+
+(60) 4.9(11) is hard to read, consider rewording. [Canada NB]
+
!wording
(1) Remove pragma Preelaborate from D.16.1(3/3).
@@ -269,7 +307,7 @@
character type to accept strings of the form "Hex_hhhhhhhh" (ignoring case) for any
character (not just the ones for which Wide_Wide_Image would produce that form --
see 3.5.2), as well as three-character strings of the form "'X'", where X is any
-character, including non-graphic characters.
+character, including nongraphic characters.
(17) Modify A.16.1(16/3):
@@ -306,7 +344,8 @@
"... The Alignment parameter is {a nonzero integral multiple of}[at least] @i<D>'Alignment
if @i<D> is a specific type, and otherwise is {a nonzero integral multiple}[at least] of
-the alignment of the specific type identified by the tag of the object being created. ..."
+the alignment of the specific type identified by the tag of the object being created{; it is
+unspecified if there is no such value}. ..."
(24) Modify A.18.2(147.13/3), A.18.2(147.16/3), A.18.3(86.6/3), A.18.3(86.9/3), A.18.4(41.6/3),
A.18.4(41.9/3), A.18.7(36.5/3), A.18.7(96.10/3), A.18.10(125/3), A.18.10(126/3):
@@ -513,31 +552,103 @@
{An invariant is checked upon}[Upon] successful return from a call on any subprogram or
entry that:
+(50) Add after 3.2.4(12/3):
+
+ "* a short-circuit control form where both operands are predicate-static; or"
+
Modify 7.3.2(18/3):
{The}[the] check is performed on each such part of type T.
+(51) Delete 13.12(7/2).
+
+Add before 13.12(9/2) (but under the Implementation Permissions header:
+
+An implementation may provide implementation-defined restrictions; the
+identifier for an implementation-defined restriction shall differ from those
+of the language-defined restrictions.
+
+Add after 13.12(14/2):
+
+Implementation Permissions
+
+An implementation may provide implementation-defined usage profiles; the
+identifier for an implementation-defined usage profile shall differ from those
+of the language-defined usage profiles.
+
+(52) In 4.1.5(2/3), "name" should be in the syntax font.
+
+(53) In 5.5.2(7/3), replace "iterator cursor subtype" with "iteration cursor subtype".
+
+(54) Add "containers" to the list in 1(2): "..., [and] random number generation{, and
+definition and use of containers}."
+
+(55) Add "with Ada.Task_Identification;" to D.16.1(3/3). In D.16.1(10-13/3), add
+"Ada.Task_Identification" in front of "Task_Id" and "Current_Task".
+
+[Note: Not using a "use clause" for Task_Id is consistent with the other packages in
+Annex D.]
+
+(56) Add "(see 9.5)" to the end of E.2.2(14.1/3).
+
+(57) Swap paragraphs A.4.11(49/3) and A.4.11(50/3).
+
+(58) Modify A.16.1(28/3): "...an external file {(including directories and special files)}
+but is not a full name..."
+
+(59) Add the following array example to 5.5.2(14/3):
+
+ -- Array component iterator example:
+ for Element of Board loop -- See 3.6.1
+ Element := Element * 2.0; -- Double each element of Board, a two-dimensional array.
+ end loop;
+
+(60) Replace 4.9(11/3) with:
+
+ a membership test whose simple_expression is a static
+ expression, and whose membership_choice_list consists only of
+ membership_choices that are either static choice_expressions,
+ static ranges, or subtype_marks that denote a static
+ (scalar or string) subtype;
+
!discussion
For (23), we copy the wording of 13.3(26.3/2).
For (34), the commenter would have preferred wording closer to the Ada 2005 wording,
something along the lines of:
-
-"For such an assignment, the result may be *built in place*, that is, directly in the
-target object and not by means of an anonymous object."
-Unfortunately, that's wrong with the model used by the Standard. The anonymous object
-always exists (even when built-in-place), it just is colocated with the target object and
-thus no copying is needed to assign it (this is called *mutation*). We had to adopt this
-(admittedly bizarre) model to deal with corner cases where it is possible to tell the
-differences between the target object and the anonymous object, which may have different
-types, tags, and finalization.
+"For such an assignment, the result may be *built in place*, that is, directly
+in the target object and not by means of an anonymous object."
-For (36), the subphrases of 4.5.2(2/3) all bind to "determines whether or not a value", and
-"has accessibility level" makes more sense than "with accessibility level" with this lead-in.
+Unfortunately, that's wrong with the model used by the Standard. The anonymous
+object always exists (even when built-in-place), it just is colocated with the
+target object and thus no copying is needed to assign it (this is called
+*mutation*). We had to adopt this (admittedly bizarre) model to deal with corner
+cases where it is possible to tell the differences between the target object and
+the anonymous object, which may have different types, tags, and finalization.
+
+For (36), the subphrases of 4.5.2(2/3) all bind to "determines whether or not a
+value", and "has accessibility level" makes more sense than "with accessibility
+level" with this lead-in.
+
+!corrigendum 1(2)
+
+@drepl
+The language includes a complete facility for the support of real-time, concurrent programming.
+Errors can be signaled as exceptions and handled explicitly. The language also covers systems
+programming; this requires precise control over the representation of data and access to
+system-dependent properties. Finally, a predefined environment of standard packages is
+provided, including facilities for, among others, input-output, string manipulation, numeric
+elementary functions, and random number generation.
+@dby
+The language includes a complete facility for the support of real-time, concurrent programming.
+Errors can be signaled as exceptions and handled explicitly. The language also covers systems
+programming; this requires precise control over the representation of data and access to
+system-dependent properties. Finally, a predefined environment of standard packages is
+provided, including facilities for, among others, input-output, string manipulation, numeric
+elementary functions, random number generation, and definition and use of containers.
-
!corrigendum 3.2.4(0)
@dinsc
@@ -555,7 +666,7 @@
character type to accept strings of the form "Hex_hhhhhhhh" (ignoring case) for any
character (not just the ones for which Wide_Wide_Image would produce that form @emdash
see 3.5.2), as well as three-character strings of the form "'@i<X>'", where @i<X> is
-any character, including non-graphic characters.
+any character, including nongraphic characters.
!corrigendum 3.10.1(13)
@@ -624,7 +735,7 @@
@fa<simple_expression> is convertible to the tested type and its
accessibility level is no deeper than that of the tested type;
further, if the designated type of the tested type is tagged and the
-@fa<simple_expression> is non-null, the tag of the object designated by the value of the
+@fa<simple_expression> is nonnull, the tag of the object designated by the value of the
@fa<simple_expression> is covered by the designated type of the tested type.>
!corrigendum 4.5.7(0)
@@ -649,6 +760,18 @@
Subpool_Handle, which is the type used to identify a subpool, declared in package
System.Storage_Pools.Subpools (see 13.11.4).
+!corrigendum 4.9(11)
+
+@drepl
+@xbullet<a membership test whose @fa<simple_expression> is a static expression,
+and whose @fa<range> is a static range or whose @fa<subtype_mark> denotes a
+static (scalar or string) subtype;>
+@dby
+@xbullet<a membership test whose @fa<simple_expression> is a static expression,
+and whose @fa<membership_choice_list> consists only of @fa<membership_choice>s
+that are either static @fa<choice_expression>s, static @fa<range>s,
+or @fa<subtype_mark>s that denote a static (scalar or string) subtype;>
+
!corrigendum 4.9(33)
@drepl
@@ -828,7 +951,8 @@
@i<D>'Max_Size_In_Storage_Elements, where @i<D> is the designated subtype of @i<T>.
The Alignment parameter is a nonzero integral multiple of @i<D>'Alignment if @i<D> is a specific
type, and otherwise is a nonzero integral multiple of the alignment of the specific type identified by
-the tag of the object being created. The Alignment parameter is no more than
+the tag of the object being created; it is
+unspecified if there is no such value. The Alignment parameter is no more than
@i<D>'Max_Alignment_For_Allocation. The result returned in the Storage_Address parameter
is used as the address of the allocated storage, which is a contiguous block of memory
of Size_In_Storage_Elements storage elements. Any exception propagated
@@ -840,6 +964,35 @@
[A placeholder to cause a conflict; the real wording is found in the conflict
file.]
+!corrigendum 13.12(7/2)
+
+@ddel
+The set of restrictions is implementation defined.
+
+!corrigendum 13.12(9)
+
+@dinsb
+An implementation may place limitations on the values of the @fa<expression>
+that are supported, and limitations on the supported combinations of
+restrictions. The consequences of violating such limitations are implementation
+defined.
+@dinst
+An implementation may provide implementation-defined restrictions; the
+identifier for an implementation-defined restriction shall differ from those
+of the language-defined restrictions.
+
+!corrigendum 13.12(9.2/1)
+
+@dinsa
+Whenever enforcement of a restriction is not required prior to execution, an
+implementation may nevertheless enforce the restriction prior to execution of a
+partition to which the restriction applies, provided that every execution of the
+partition would violate the restriction.
+@dinst
+An implementation may provide implementation-defined usage-profiles; the
+identifier for an implementation-defined usage profile shall differ from those
+of the language-defined usage profiles.
+
!corrigendum 13.12.1(2/2)
@dinsa
@@ -1163,6 +1316,18 @@
with a lower-numbered category being "earlier in the hierarchy" in the sense of
the previous paragraph:
+!corrigendum E.2.2(14/2)
+
+@dinsa
+@xbullet<The primitive subprograms of the corresponding specific limited private
+type shall only have access parameters if they are controlling formal
+parameters; each noncontrolling formal parameter shall support external
+streaming (see 13.13.2);>
+@dinst
+
+@xbullet<The corresponding specific type shall not have a primitive procedure
+with the Synchronization aspect specified unless the @fa<synchronization_kind>
+is Optional (see 9.5);>
!ACATS Test
None needed.
@@ -1313,6 +1478,445 @@
****************************************************************
From: Randy Brukardt
+Sent: Friday, January 13, 2012 12:50 AM
+
+Steve's review includes:
+
+> In 13.12(7/2), we have
+> The set of restrictions is implementation defined.
+>
+> Do we need a similar rule for usage profiles somewhere?
+
+This rule seems wrong for restrictions, so I don't want one like it for
+profiles. I don't know why it is under "Static Semantics". For attributes and
+pragmas, the similar rule is an "Implementation Permission". And the wording
+above seems to allow the implementation to not implement language-defined
+restrictions (it doesn't say anything about "adding" restrictions). I doubt that
+is what we want!
+
+So I'd suggest something like
+
+Implementation Permissions
+
+An implementation may provide implementation-defined restrictions and usage
+profiles.
+
+Or possibly two sentences (one before paragraph 9 for restrictions, and the
+other after paragraph 14 for profiles).
+
+And delete the existing rule.
+
+What does everyone else think?
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, January 13, 2012 8:58 AM
+
+I agree with your approach.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Friday, January 13, 2012 11:19 AM
+
+Ditto. Specifically, I agree with your second approach (consistent treatment of
+restrictions and profiles).
+
+****************************************************************
+
+From: Tullio Vardanega
+Sent: Friday, January 13, 2012 11:30 AM
+
+I also agree with the second of Randy's suggested approaches.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, January 13, 2012 11:36 AM
+
+>> What does everyone else think?
+
+Do we want to add
+
+but may not extend or modify any of the language defined restrictions or usage
+profiles.
+
+(same rule as for pragmas, perhaps implied, but I think useful to make it
+explicit).
+
+****************************************************************
+
+From: Tullio Vardanega
+Sent: Friday, January 13, 2012 11:47 AM
+
+Yes, it does sound like a useful precaution to me.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, January 13, 2012 11:47 AM
+
+> Do we want to add
+>
+> but may not extend or modify any of the language defined restrictions
+> or usage profiles.
+
+We may not use "may not" in ISO standards.
+Shall not we all use "shall not" instead? ;-)
+
+> (same rule as for pragmas, perhaps implied, but I think useful to make
+> it explicit).
+
+Does seem a bit redundant, since we disallow any of this sort of thing in
+general.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, January 13, 2012 11:51 AM
+
+Well it always seems very odd to me to allow new pragmas, but not impl added
+extensions to existing pragmas and results in awkward work arounds, so I think
+this is worth saying. in impl advice we try to be clear rather than
+non-redundantly formal :-)
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Friday, January 13, 2012 1:11 PM
+
+We shall use shall not, so the sentence shall read:
+
+"but shall not extend or modify any of the language defined restrictions or
+usage profiles."
+
+Shall we agree? ;-)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, January 13, 2012 1:37 PM
+
+...
+> Do we want to add
+>
+> but may not extend or modify any of the language defined restrictions
+> or usage profiles.
+>
+> (same rule as for pragmas, perhaps implied, but I think useful to make
+> it explicit).
+
+There is no such rule for pragmas (I checked these before I sent my original
+message). The only thing that is said 2.9(14) is that an implementation-defined
+pragma has a different name, which would have said here:
+
+"the identifier for an implementation-defined restriction shall differ from
+those of the language-defined restrictions"
+
+but this is nonsense for restrictions because the names have to be unique
+anyway.
+
+There is nothing about "extend or modify", presumably because that goes without
+saying anyway. An implementation is allowed to *add* pragmas, attributes,
+aspects, and restrictions, but is it *never* allowed to change a
+language-defined one. Even if the item is defined in an annex that you're not
+implementing. See 1.1.3, and especially 1.1.3(17/3).
+
+I could be convinced to add the above text (to match pragmas and attributes),
+but I would be against saying any more. I can't imagine why people would have to
+be told not to extend restrictions and not told the same thing about pragmas.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, January 13, 2012 1:51 PM
+
+...
+> There is no such rule for pragmas (I checked these before I sent my
+> original message). The only thing that is said 2.9(14) is that an
+> implementation-defined pragma has a different name, which would have
+> said
+> here:
+
+I think there is dwefinitely intended to be a rule that you can't modify or
+extend language defined pragmas. Do you really believe that is not the case,
+because if so, there are several places we would be delighted to extend existing
+language pragmas in GNAT :-)
+
+> There is nothing about "extend or modify", presumably because that
+> goes without saying anyway. An implementation is allowed to *add*
+> pragmas, attributes, aspects, and restrictions, but is it *never*
+> allowed to change a language-defined one. Even if the item is defined
+> in an annex that you're not implementing. See 1.1.3, and especially 1.1.3(17/3).
+
+OK, now I am confused, you said there was no such rule for pragmas, and then you
+say it "goes without saying", not clear to me. It would seem quite reasonable to
+say that implementations must intepret language defined pragmas as defined in
+the RM, but are allowed to e.g. add arguments.
+
+> I could be convinced to add the above text (to match pragmas and
+> attributes), but I would be against saying any more. I can't imagine
+> why people would have to be told not to extend restrictions and not
+> told the same thing about pragmas.
+
+I think they should be told that for pragmas, and "goes without saying"
+is not exactly a recognized principle in defining language rules.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, January 13, 2012 1:56 PM
+
+By the way, for my taste I see no difference between an implementation defined
+aspect that will blow up any compiler not recognizing it, and an extension to a
+language defined aspect that will blow up any compiler not recognzing it.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Friday, January 13, 2012 2:25 PM
+
+> I think there is dwefinitely intended to be a rule that you can't
+> modify or extend language defined pragmas. Do you really believe that
+> is not the case, because if so, there are several places we would be
+> delighted to extend existing language pragmas in GNAT :-)
+
+I agree with everyone else, that the second part of Randy's is a better
+approach. I also agree with Robert, that it is good to be clear about
+altering/extending language defined pragmas. I don't think it hurts to be more
+precise, if we are making a change in this area anyway.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, January 13, 2012 2:46 PM
+
+> I think there is dwefinitely intended to be a rule that you can't
+> modify or extend language defined pragmas. Do you really believe that
+> is not the case, because if so, there are several places we would be
+> delighted to extend existing language pragmas in GNAT :-)
+
+There is no such rule, because there is a rule that you can't modify or extend
+*anything* in Ada. So why mention this specifically for pragmas? (And not for
+attributes or if statements or subprograms?)
+
+> > There is nothing about "extend or modify", presumably because that
+> > goes without saying anyway. An implementation is allowed to *add*
+> > pragmas, attributes, aspects, and restrictions, but is it *never*
+> > allowed to change a language-defined one. Even if the item is
+> > defined in an annex that you're not implementing. See 1.1.3, and
+> > especially
+1.1.3(17/3).
+>
+> OK, now I am confused, you said there was no such rule for pragmas,
+> and then you say it "goes without saying", not clear to me. It would
+> seem quite reasonable to say that implementations must intepret
+> language defined pragmas as defined in the RM, but are allowed to e.g.
+> add arguments.
+
+You missed my point. There is a blanket rule in 1.1.3 that you can't modify or
+extend anything in Ada. (It doesn't say that in those exact words, which is why
+I didn't give a paragraph reference, but it's clear if you read the entire
+section that that is the intent.) So pragmas don't say this explicitly, because
+it is true of everything in the Standard; it goes without saying it (other than
+in the introduction of the Standard).
+
+> > I could be convinced to add the above text (to match pragmas and
+> > attributes), but I would be against saying any more. I can't imagine
+> > why people would have to be told not to extend restrictions and not
+> > told the same thing about pragmas.
+>
+> I think they should be told that for pragmas, and "goes without saying"
+> is not exactly a recognized principle in defining language rules.
+
+OK, but no one has ever (previously) complained that there isn't enough text in
+the pragma section, and I think this is a dangerous precedent to set. Once you
+mention that something cannot be "modified or extended", that suggests that
+other things that don't say that might be able to be extended. So then you have
+to add that wording to many (or all) places where implementation-defined
+behavior is allowed.
+
+So I'm still against (normatively) repeating something that is *always* true in
+specific places as if there is some difference in those specific places. I could
+be convinced that a note would be worthwhile -- but given that this is unchanged
+since Ada 95, I'm very dubious that there is any need.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, January 13, 2012 2:56 PM
+
+> There is no such rule, because there is a rule that you can't modify
+> or extend *anything* in Ada. So why mention this specifically for
+> pragmas? (And not for attributes or if statements or subprograms?)
+
+There is no such rule! And you can extend something in Ada, notably the set of
+pragmas, or the set of aspects, or even the syntax for aspects.
+
+I think it is not obvious at all that you can add a pragma, but not add a
+parameter to an existing pragma. Or add an attribute, but not extend the
+applicability of an existing attribute.
+
+I always hate arguments where we have
+
+A: I think X is unclear, we should clarify it
+
+B; I think it's clear, so I disagree
+
+But A is simply saying that there are some people who find it unclear and that's
+a pretty strong argument that it is worth clarifying. B's argument does not
+contradict this, there is a difference between "there exists" and "for all".
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, January 13, 2012 3:15 PM
+
+I tend to agree with Randy on this one. I see no strong reason to add verbiage
+beyond what is already in paragraph 1.1.3(17/3).
+
+Here are some of the relevant paragraphs from 1.1.3:
+
+1 A conforming implementation shall:
+
+...
+
+6 Contain no variations except those explicitly permitted by this International
+ Standard, or those that are impossible or impractical to avoid given the
+ implementation's execution environment;
+
+7 Specify all such variations in the manner prescribed by this International
+ Standard.
+
+...
+
+16 An implementation that conforms to this Standard shall support each
+ capability required by the core language as specified. In addition, an
+ implementation that conforms to this Standard may conform to one or more
+ Specialized Needs Annexes (or to none). Conformance to a Specialized Needs
+ Annex means that each capability required by the Annex is provided as
+ specified.
+
+17/3 An implementation conforming to this International Standard may provide
+ additional aspects, attributes, library units, and pragmas. However, it
+ shall not provide any aspect, attribute, library unit, or pragma having the
+ same name as an aspect, attribute, library unit, or pragma (respectively)
+ specified in a Specialized Needs Annex unless the provided construct is
+ either as specified in the Specialized Needs Annex or is more limited in
+ capability than that required by the Annex. A program that attempts to use
+ an unsupported capability of an Annex shall either be identified by the
+ implementation before run time or shall raise an exception at run time.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, January 13, 2012 3:24 PM
+
+> I always hate arguments where we have
+>
+> A: I think X is unclear, we should clarify it
+>
+> B; I think it's clear, so I disagree
+
+Sure, but if B explains why it's clear, then A can become convinced.
+Hopefully A isn't sticking his fingers in his ears and shouting "La La La La".
+;-)
+
+But I don't think we should even be discussing this. Our current job is to get
+the Ada 2012 changes right. If something about pragmas is unclear, it's been
+unclear since 1983, and we're not in the business of fixing such things right
+now.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Friday, January 13, 2012 3:57 PM
+
+> Sure, but if B explains why it's clear, then A can become convinced.
+> Hopefully A isn't sticking his fingers in his ears and shouting "La La
+> La La". ;-)
+
+As an example of this,
+Tuckers previous email and Randy's latest arguments have cause me to join the
+rank of the convinced. I think the original suggested change (Randy's part 2) is
+fine without having to mention disallowing modification or extending language
+defined pragmas.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, January 13, 2012 4:34 PM
+
+Please recall that my initial concern was with aspects, we allow aspects to be
+added, and leave it completely free what the syntax will be, but I guess we
+don't want to allow a new aspect whose specified syntax looks like an extension
+of an existing aspect :-)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, January 13, 2012 4:38 PM
+
+But no big deal, I really think that all these discussions of details in wording
+of the RM don't matter much :-)
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, January 13, 2012 5:16 PM
+
+> > Please recall that my initial concern was with aspects, we allow
+> > aspects to be added, and leave it completely free what the syntax
+> > will be, but I guess we don't want to allow a new aspect whose
+> > specified syntax looks like an extension of an existing aspect :-)
+
+Oh, OK, I suppose that should be clarified.
+
+I haven't read the whole thread, in which case I'd normally keep my mouth shut,
+but I just wanted to avoid a long discussion of some Ada 83 rules that may or
+may not be clear. I'll try to comment about the aspects after reading the whole
+thread.
+
+> But no big deal, I really think that all these discussions of details
+> in wording of the RM don't matter much :-)
+
+Yes, I generally agree.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, January 13, 2012 5:34 PM
+
+> > > Please recall that my initial concern was with aspects, we allow
+> > > aspects to be added, and leave it completely free what the syntax
+> > > will be, but I guess we don't want to allow a new aspect whose
+> > > specified syntax looks like an extension of an existing aspect :-)
+>
+> Oh, OK, I suppose that should be clarified.
+
+Well, we originally were talking about "profiles" and "restrictions"; nothing to
+do with aspects. I don't recall anyone ever saying anything about the wording of
+aspects (and I know I've not looked at it lately).
+
+The original question from Steve is whether we needed a rule allowing
+implementation-defined profiles, and the answer to that is clearly yes. But I
+then complained about the Ada 95 rule for restrictions (which in the same
+clause, so it's relevant for consistency reasons), which appears to allow
+anything for those (including not implementing language-defined ones; it's nice
+to know that the non-existent Janus/Ada implementation of restrictions is
+conforming :-).
+
+I should probably have just done the right thing and let people complain about
+it in Houston. An attempt to get confirmation that my understanding is right has
+led off into a huge waste of time for everyone involved (and I've only gotten a
+weak confirmation of my original question).
+
+So, please don't waste *your* time reading the whole thread.
+
+****************************************************************
+
+From: Randy Brukardt
Sent: Friday, January 27, 2012 1:53 AM
A couple of weeks ago, I responded to one of Steve's comments thusly:
@@ -1352,6 +1956,201 @@
****************************************************************
+From: Tucker Taft
+Sent: Friday, January 27, 2012 7:14 AM
+
+> ...
+> The Alignment parameter is a nonzero integral multiple of D'Alignment
+> if D is a specific type, and otherwise is a nonzero integral multiple
+> the
+
+ "of" -------^^
+
+> alignment of the specific type identified by the tag of the object
+> being created.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Friday, January 27, 2012 11:36 AM
+
+...
+> The Alignment parameter is a nonzero integral multiple of D'Alignment
+> if D is a specific type, and otherwise is a nonzero integral multiple
+> of the alignment of the specific type identified by the tag of the
+> object being created.
+
+A nonzero integral multiple of D'Alignment may be difficult to find in
+the case where D'Alignment = 0.
+
+****************************************************************
+
+From: Dan Eilers
+Sent: Friday, January 27, 2012 11:50 AM
+
+Depends on how you hypenate it.
+
+A nonzero-integral-multiple of D'Alignment is easier to find than a nonzero
+integral-multiple-of-D'Alignment.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, January 27, 2012 2:42 PM
+
+> A nonzero integral multiple of D'Alignment may be difficult to find in
+> the case where D'Alignment = 0.
+
+True enough. But I don't think we want the Alignment parameter to be zero even in
+that case, so we need the "nonzero integral" part anyway. And it really doesn't
+make sense for a subtype (as opposed to an object) to have an alignment of zero;
+I can't imagine a why a compiler would want to bit-pack stand-alone objects.
+
+So, in the interest of not making this even more complicated, I'd suggest just adding
+a To-Be-Honest:
+
+If D'Alignment is zero, then it is not strictly possible to have a "nonzero integral
+multiple" of the alignment; in that case, any nonzero alignment may be passed.
+
+I don't see any decent way to talk about the other case of alignment in this note, either.
+
+The only other practical option that I see is to back out the change and return to the
+original "at least" wording (it's at least not wrong in obscure cases, it just allows
+too much). It's not practical put a condition on the text as is found in 13.3(26.3/2),
+because that requires referring to the alignment of the type to be passed twice, and I can't
+find a reasonable way to talk about that once (as in the note above), much less twice.
+
+So, please tell me whether:
+(A) fix this with a TBH;
+(B) revert to the original wording; or
+(C) propose some wording that actually works.
+[Bob being the person who originally wanted a change here, he is not allowed to chose (B). :-)]
+
+****************************************************************
+
+From: Steve Baird
+Sent: Friday, January 27, 2012 6:40 PM
+
+Append to previous wording:
+ The value of the Alignment parameter is unspecified if D'Alignment
+ is zero.
+
+I suppose that to be precise we should handle the oddball case first and then begin
+the normal case with "Otherwise, ".
+
+Let's not.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, January 27, 2012 6:53 PM
+
+My objection to that is that it doesn't cover the other zero case, that is when "the
+alignment of the specific type identified by the tag of the object being created" is
+zero. That is such a mouthful that repeating it is horrible. We'd have to factor it out
+somehow.
+
+Try:
+
+Given that the alignment A for a call to Allocate is D'Alignment if D is a specific type,
+and otherwise is a nonzero integral multiple of the alignment of the specific type
+identified by the tag of the object being created, the Alignment parameter is a nonzero
+integral multiple of A if A is nonzero, and is unspecified otherwise.
+
+Or something like that. But I'm really dubious that it is worth this much hassle to deal
+with a case that should never happen anyway. (Why do we even allow subtypes to have a zero
+alignment? It's only meaningful for objects.)
+
+****************************************************************
+
+From: Steve Baird
+Sent: Friday, January 27, 2012 7:12 PM
+
+How about
+
+ The value of the Alignment parameter is unspecified if D'Alignment
+ (or the alignment of the corresponding specific type if D is
+ classwide) is zero.
+
+?
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, January 27, 2012 8:20 PM
+
+How could a classwide type possibly have an alignment of zero?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, January 27, 2012 8:43 PM
+
+It's not talking about the alignment of the class-wide type, but rather
+the alignment of some specific type that belongs to it.
+And the language allows such an alignment to be specified, and a compiler
+could support it, and the wording needs to make sense if that happens.
+
+Now, does it make *sense* to specify such an alignment? No. Indeed, I don't
+think it makes sense ever to have a zero alignment on any subtype (as opposed
+to an object), because the requirements for independence prevent any sort of
+bit packing of objects or components unless it is explicitly requested by a
+rep item on that object or (type containing that) component.
+Nevertheless, it is allowed and the wording needs to make sense.
+
+To answer Steve, I don't much like the two sentence solution, because you have
+two sentences that give conflicting information about a single value.
+It's OK to have two sentences if they are disjoint cases, but that's not true here.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, January 27, 2012 8:51 PM
+
+> Now, does it make *sense* to specify such an alignment? No. Indeed, I
+> don't think it makes sense ever to have a zero alignment on any
+> subtype (as opposed to an object), because the requirements for
+> independence prevent any sort of bit packing of objects or components
+> unless it is explicitly requested by a rep item on that object or (type containing
+> that) component. Nevertheless, it is allowed and the wording needs to make sense.
+
+Well tagged types in particular are always going in practice to have at least
+pointer alignment :-)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, January 27, 2012 9:05 PM
+
+Right. Alignment zero can really only make sense for discrete types, and even then
+it seems dubious for a subtype. (You'll almost always use more code than you would
+save in memory, and the independence requirements make it unlikely anyway.) It makes
+sense that the alignment of an object can be 0 (which it is the component of a packed
+composite type), but I can't quite see any case when you should specify it to be zero
+(and I don't think would ever be zero by default for a subtype).
+
+Anyway, what we're talking about is the definition of what gets passed to a storage pool.
+I don't think it makes much sense to ask a pool for unaligned memory, so I'm dubious
+about the "unspecified" part of this. But I suppose we don't want to require something
+that we didn't require in the past, and it appears that it is OK to pass 0 to a pool.
+Why, I don't know.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Saturday, January 28, 2012 1:33 AM
+
+> (C) propose some wording that actually works.
+
+The Alignment parameter is a nonzero integral multiple of D'Alignment (unless D'Alignment
+is zero) ...
+
+The Alignment parameter is an integral nonzero multiple of D'Alignment...
+
+The Alignment parameter is D'Alignment or an nonzero integral multiple thereof...
+
+****************************************************************
+
From: Alan Burns
Sent: Monday, September 19, 2011 4:51 AM
@@ -1366,6 +2165,68 @@
****************************************************************
+!topic Another 3.2.4(12) nitpick
+!reference RM12 3.2.4(12/3)
+!from Adam Beneschan 11-11-14
+!discussion
+
+One other thing about 3.4.2(12):
+
+ a call to a predefined boolean logical operator, where both operands
+ are predicate-static; ...
+
+Since this says "logical operator", it would appear to exclude the short-circuit
+control forms; the wording of 4.5.1 means that "and then" and "or else" aren't
+operators. Is there a valid reason for excluding them in static predicates? The
+way the rest of the section on static predicates is worded, I believe that there is
+no way it could possibly make a semantic difference whether "and" or "and then"
+is used, and similarly "or" vs. "or else". However, I suspect there are Ada
+programmers who habitually use the short-circuit forms (in my experience, there are
+very few circumstances where it's *necessary* to use the logical operator form on
+boolean operands), and it seems potentially frustrating to those programmers to force
+them to go against their habit when there doesn't seem to be a good reason for
+requiring this.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, November 15, 2011 9:11 AM
+
+...
+> Since this says "logical operator", it would appear to exclude the
+> short-circuit control forms; the wording of 4.5.1 means that "and
+> then" and "or else" aren't operators. Is there a valid reason for
+> excluding them in static predicates?
+
+Excluding the short-circuits was deliberate. The AI makes that clear. I don't
+remember whether the AI gives any compelling reason -- probably just that they're
+not needed.
+
+(In general, when asking "why" the 2012 RM is the way it is, it's a good idea to look
+at the AI's, because not all of the rationale has made it into AARM annotations. For
+this particular AI, that's due to laziness on my part.)
+
+>...The way the rest of the section
+> on static predicates is worded, I believe that there is no way it
+>could possibly make a semantic difference whether "and" or "and then"
+> is used, and similarly "or" vs. "or else".
+
+Yes, the AI points that out.
+
+>...However, I suspect there
+> are Ada programmers who habitually use the short-circuit forms (in my
+>experience, there are very few circumstances where it's *necessary* to
+>use the logical operator form on boolean operands), and it seems
+>potentially frustrating to those programmers to force them to go
+>against their habit when there doesn't seem to be a good reason for
+>requiring this.
+
+I'd probably be convinced by this argument if it weren't so late in the game.
+
+[Editor's note: This discussion was restarted on February 2nd.]
+
+****************************************************************
+
From: Brad Moore
Sent: Wednesday, December 28, 2011 10:29 AM
@@ -1501,6 +2362,227 @@
****************************************************************
From: Randy Brukardt
+Sent: Thursday, February 2, 2012 11:18 PM
+
+Bob Duff writes:
+> "Randy Brukardt" <randy@rrsoftware.com> wrote:
+> > Not very-related aside: Do you think that short-circuit forms should
+> > be allowed in predicate-static expressions? Those of us who almost
+> > exclusively use "and then" and "or else" will be annoyed every time
+> > the compiler complains here.
+>
+> It was a very deliberate decision to leave them out. But I suppose I
+> wouldn't object to allowing them. AdaCore style is to use "and then"
+> in preference to "and". My own personal style is to use "and" unless
+> "and then" is necessary.
+
+The reason I asked is that Ed rejected my suggestion that this be on the Houston
+agenda, and I'm looking for a second to override that. (Note that I agree that
+it isn't by any means the most important thing, and if we run out of time it
+would be a good candidate to skip, but that doesn't mean that we shouldn't have
+the discussion if we have the time.)
+
+RRS has the same style preference to use "and then" as AdaCore. It originally
+was rooted in efficiency concerns on the Z80 processor (branching took fewer
+instructions than constructing a boolean value, and we had no optimizer in those
+days to convert expression to more efficient forms - it wouldn't have fit in the
+48K bytes(!!) that we had available then). But I much prefer Robert's
+justification for AdaCore's style, so I should claim that as the reason. :-)
+
+Anyway, since I reflexively write "and then", I am certain to be aggravated
+every time I write a static predicate. (At least the error would be at the point
+of declaring the predicate, and not a hundred packages later when I try to use
+it in a case statement somewhere.) This is the kind of pointless annoyance that
+Ada is famous for (especially in Ada 83), and I'd rather not introduce another
+one. I'd give pretty good odds that we'll end up changing it next time to smooth
+off a bump, so why not consider doing it now and spare everyone the aggravation?
+
+So someone out there say "yea, verily", and I'll make an AI to discuss in
+Houston. If I'm completely alone on this, well, I'll just forget it...
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Friday, February 3, 2012 6:13 AM
+
+> So someone out there say "yea, verily", and I'll make an AI to discuss
+> in Houston. If I'm completely alone on this, well, I'll just forget it...
+
+yea, verily.
+
+(To push people into if..then..else to say
+ "X /= Null and then X.C = ..."
+ is ...<censored> ... )
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, February 3, 2012 8:57 AM
+
+I also say "yea verily verily yea" (those who know Court Jester will have a
+chant rhythm in their heads when they read this :-))
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Friday, February 3, 2012 9:23 AM
+
+Just speaking as a random user it would seem bizarre to me not to allow it.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, February 3, 2012 8:04 AM
+
+>> It was a very deliberate decision to leave them out. But I suppose I
+>> wouldn't object to allowing them. AdaCore style is to use "and then"
+>> in preference to "and". My own personal style is to use "and" unless
+>> "and then" is necessary....
+
+I see no reason not to include "and then." I remember asking George Romanski,
+who is the "main man" when it comes to FAA DO-178Level A certification, and he
+recommended always using short-circuit in that sort of code. Something about
+the number of test vectors.
+
+Why not include them, other than for personal preference reasons?
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, February 3, 2012 9:26 AM
+
+> I see no reason not to include "and then."
+
+I agree. The AI doesn't explain why I left them out.
+I think it was just that they're not really needed, combined with the fact that
+I was afraid the "statically unevaluated" stuff would be a (small) can of worms.
+But now I think it's not a problem.
+
+>...I remember asking
+> George Romanski, who is the "main man" when it comes to FAA
+>DO-178Level A certification, and he recommended always using
+>short-circuit in that sort of code. Something about the number of
+>test vectors.
+
+I'm dubious about arguments based on DO-178B. Airplanes are very safe, but I
+don't think anybody knows whether DO-178B is responsible for that, nor if so,
+why.
+
+> Why not include them, other than for personal preference reasons?
+
+Did you mean to say, "Why not include them, for personal preference reasons?"
+AFAICS, the only reason to allow them is to accommodate personal preference.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, February 3, 2012 9:17 AM
+
+No doubt Randy will want wording.
+I suggest adding after RM-3.2.4(12/3):
+
+ a short-circuit control form where both operands
+ are predicate-static; or
+
+Note that I'm not messing around with anything analogous to the "statically
+unevaluated" stuff.
+
+...
+> (To push people into if..then..else to say
+> "X /= Null and then X.C = ..."
+> is ...<censored> ... )
+
+That's not predicate static in any case. In fact, as far as I can see, "and"
+has identical semantics to "and then" in predicate-static expressions. There is
+no case where "and then" is needed to protect from an exception in the second
+operand. Can anybody think of a counter-example to prove me wrong? This:
+
+ subtype S is Integer with
+ Static_Predicate => False and then (Blah / 0) = 0;
+
+is illegal (given my above wording), and so is this:
+
+ subtype S is Integer with
+ Static_Predicate => False and then (1 / S) = 0;
+
+I don't see any way to sneak in a divide by zero, nor any other exception.
+
+So the only reason to allow "and then" is because people like it.
+A coding convention "always use and then" is simpler and therefore better than
+"always use and then, except when it's illegal".
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, February 3, 2012 11:18 PM
+
+> No doubt Randy will want wording.
+
+Well, actually, I was going to write it myself (ye how asks and all of that),
+but thanks for doing it anyway.
+
+> I suggest adding after RM-3.2.4(12/3):
+>
+> a short-circuit control form where both operands
+> are predicate-static; or
+>
+> Note that I'm not messing around with anything analogous to the
+> "statically unevaluated" stuff.
+
+I would never have even thought to care about that. A predicate that always
+evaluates to False (or True for that matter) is not very useful, and I don't
+see any reason to bend over backwards to support it.
+
+...
+> > yea, verily.
+> >
+> > (To push people into if..then..else to say
+> > "X /= Null and then X.C = ..."
+> > is ...<censored> ... )
+>
+> That's not predicate static in any case.
+
+You failed to mention why: dereferencing is not predicate-static, and it
+couldn't make sense for it to be so. I briefly was confused because X /= null
+surely is predicate-static.
+
+> In fact, as far as
+> I can see, "and" has identical semantics to "and then" in
+> predicate-static expressions. There is no case where "and then" is
+> needed to protect from an exception in the second operand.
+
+Right, in large part because we don't allow any math operators in these
+expressions (they of course can be used in any constituent static expressions).
+
+> Can anybody think of a counter-example to prove me wrong? This:
+>
+> subtype S is Integer with
+> Static_Predicate => False and then (Blah / 0) = 0;
+>
+> is illegal (given my above wording), and so is this:
+>
+> subtype S is Integer with
+> Static_Predicate => False and then (1 / S) = 0;
+>
+> I don't see any way to sneak in a divide by zero, nor any other
+> exception.
+
+Well, invalid values might raise Constraint_Error or Program_Error. But we
+didn't try to protect against that here, and anyway, those exceptions could
+rightfully be blamed on the evaluation of the value before the predicate is
+evaluated. Otherwise, I don't see anyway for a reference to a current instance,
+a comparison against it, a membership expression using it, or a case expression
+using it to raise an exception.
+
+> So the only reason to allow "and then" is because people like it.
+> A coding convention "always use and then" is simpler and therefore
+> better than "always use and then, except when it's illegal".
+
+And a lot less aggravating. :-)
+
+****************************************************************
+
+From: Randy Brukardt
Sent: Saturday, February 4, 2012 12:35 AM
7.3.2(14-15/3) says:
@@ -2790,5 +3872,155 @@
The latest formulation is becoming digestible even to the likes of me.
Perhaps this counts as an indication of convergence ;-)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, February 17, 2012 12:36 AM
+
+The following is literally the last comment that I have to address:
+
+>4.9 (11/3) a membership test whose simple_expression is a static
+> expression, and whose membership_choice_list consists only of
+> membership_choices each of which is either a static
+>choice_expression,
+> a static range, or a subtype_mark that denotes a static
+> [(scalar or string)] subtype;
+>
+> this sentence might need to be improved for readability,
+>
+>Suggested rewording...
+>
+>" a membership test whose simple_expression is a static expression and
+> whose membership_choice_list consists only of membership_choices that
+> are one of the following:
+> - a static choice_expression; or
+> - a static range; or
+> - a subtype_mark that denotes a static (scalar or string) subtype;"
+>
+>or alternatively,
+>
+>" a membership test whose simple_expression is a static expression and
+> whose membership_choice_list consists only of membership_choices that
+> must be one of; a static choice_expression, a static range, or a
+> subtype_mark that denotes a static (scalar or string) subtype;"
+
+We can't use "must" in normative wording, and its replacement "shall" should
+only apply to Legality Rules and the like, so the second choice is out.
+
+Using the bullets within a bulleted list can be confusing (it's out of context
+here, of course), so I'm unconvinced that it is an improvement.
+
+I suppose we could use a variation on the second choice:
+
+" a membership test whose simple_expression is a static expression and
+ whose membership_choice_list consists only of membership_choices that
+ are be one of: a static choice_expression, a static range, or a
+ subtype_mark that denotes a static (scalar or string) subtype;"
+
+But I find the embedded colon weird, so I don't have a clear answer. I still
+prefer the original wording.
+
+Any thoughts? (Must arrive here by 2pm tomorrow.)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, February 17, 2012 8:37 AM
+
+> But I find the embedded colon weird, so I don't have a clear answer. I
+> still prefer the original wording.
+
+I prefer the bulleted sub-list or the original wording.
+With the bulleted sub-list, I would stick with the singular, namely:
+
+ a membership test whose simple_expression is a static expression and
+ whose membership_choice_list consists of membership_choices each
+ of which is one of the following:
+ - a static choice_expression; or
+ - a static range; or
+ - a subtype_mark that denotes a static (scalar or string) subtype;
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Friday, February 17, 2012 12:03 PM
+
+> Any thoughts? (Must arrive here by 2pm tomorrow.)
+
+I would stick with the original wording, which I find acceptable.
+
+... except, not being able to leave well enough alone, I'd add a comma before
+"each of which":
+
+4.9 (11/3) a membership test whose simple_expression is a static
+ expression, and whose membership_choice_list consists only of
+ membership_choices{,} each of which is either a static choice_expression,
+ a static range, or a subtype_mark that denotes a static
+ [(scalar or string)] subtype;
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, February 17, 2012 12:14 PM
+
+> 4.9 (11/3) a membership test whose simple_expression is a static
+> expression, and whose membership_choice_list consists only of
+> membership_choices{,} each of which is either a static choice_expression,
+> a static range, or a subtype_mark that denotes a static
+> [(scalar or string)] subtype;
+
+I don't see the need to say "consists only of." Why not simply "consists of"? The only things allowed in a membership_choice_list are membership_choices.
+The "only" is redundant with "each of which" if that was its purpose.
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Friday, February 17, 2012 3:14 PM
+
+I agree, now that you point it out, that "only" doesn't make sense.
+After all, membership_choices are the only things there can be.
+If we take that out, then a comma shouldn't be added.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, February 17, 2012 7:50 PM
+
+Odd. I thought it still was needed:
+
+4.9 (11/3) a membership test whose simple_expression is a static
+ expression, and whose membership_choice_list consists of
+ membership_choices, each of which is either a static choice_expression,
+ a static range, or a subtype_mark that denotes a static
+ [(scalar or string)] subtype;
+
+"...consists of membership_choices each of which is..." doesn't seem right to
+me. But with the comma in, the middle part of kinda silly (a choice list made of
+up of choices, who'da thunk it??)
+
+Maybe the problem isn't the "only", but the "each of which". Try getting rid of
+it and make the items plural:
+
+4.9 (11/3) a membership test whose simple_expression is a static
+ expression, and whose membership_choice_list consists only of
+ membership_choices that are either static choice_expressions,
+ static ranges, or subtype_marks that denote a static
+ [(scalar or string)] subtype;
+
+Of course, we had something like this early on, and it got changed to the
+current one. I know Tucker prefers singular terms, but I don't think we should
+worry about that if it is damaging comprehension.
+
+Last call for better ideas...
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Saturday, February 18, 2012 10:45 AM
+
+I still prefer singular wherever possible, but using "that" instead of "each
+of which" in this case does get some benefit, and means that the "only" is not
+redundant. So I can live with your suggestion.
****************************************************************
Questions? Ask the ACAA Technical Agent