CVS difference for ai12s/ai12-0125-3.txt

Differences between 1.8 and version 1.9
Log of other versions for file ai12s/ai12-0125-3.txt

--- ai12s/ai12-0125-3.txt	2016/08/06 00:30:29	1.8
+++ ai12s/ai12-0125-3.txt	2016/08/16 01:32:15	1.9
@@ -94,7 +94,7 @@
     *A*, where the local anonymous procedure has an in out parameter with
     unique name *P* of subtype *S*, with a body being *A* with the
     *variable_*name being replaced by *P*, and any target_names being replaced
-    by the qualified expression *S*'(*P*). 
+    by the qualified expression *S*'(*P*).
 
     [Editor's note: We use a qualified expression here to ensure the
     replacement has the semantics of a constant view. I would have preferred
@@ -117,7 +117,7 @@
                   [Target] := [Target_Subtype]'([Target])*2 +
                               [Target_Subtype]'([Target])/2;
                end [Anon];
- 
+
             begin
                [Anon] ([Target] => My_Array(I));
             end;
@@ -144,7 +144,7 @@
      *A* contains one or more target_names.
 
 !examples
-  
+
    X := @ + 1;  --  An abbreviation for X := X + 1;
 
    A(I) := Integer'Max (@, 10);  --  Equivalent to:
@@ -239,7 +239,7 @@
             Quarter_Item_Data (Data.By_Month (Year, Quarter_Num (Month)))
                  (Quarter_Item (Month)).View_Count := @ + Amount;
             if not Is_Scanner then
-                Data.Total.Non_Scanner_View_Count := @ + Amount; 
+                Data.Total.Non_Scanner_View_Count := @ + Amount;
                 Quarter_Item_Data (Data.By_Month (Year, Quarter_Num (Month)))
                      (Quarter_Item (Month)).Non_Scanner_View_Count :=
                      @ + Amount;
@@ -328,7 +328,7 @@
  (1) It is more flexible; it can be used in function calls other than operators
      (as shown by the 'Max and Clamp examples above).
  (2) There is a positive indication that this notation is being used (the
-     addition of an @ as opposed to deleting an '='); 
+     addition of an @ as opposed to deleting an '=');
  (3) It doesn't (directly) depend on visibility of anything; it's always
      available unless the LHS of the assignment is overloaded.
 
@@ -429,7 +429,7 @@
 of @i<A>, where the local anonymous procedure has an @b<in out> parameter with
 unique name @i<P> of subtype @i<S>, with a body being @i<A> with the
 @i<variable_>@fa<name> being replaced by @i<P>, and any @fa<target_name>s
-being replaced by the qualified expression @i<S>'(@i<P>). 
+being replaced by the qualified expression @i<S>'(@i<P>).
 
 @s8<@i<Examples>>
 
@@ -649,7 +649,7 @@
             Quarter_Item_Data (Data.By_Month (Year, Quarter_Num (Month)))
                  (Quarter_Item (Month)).View_Count := @ + Amount;
             if not Is_Scanner then
-                Data.Total.Non_Scanner_View_Count := @ + Amount; 
+                Data.Total.Non_Scanner_View_Count := @ + Amount;
                 Quarter_Item_Data (Data.By_Month (Year, Quarter_Num (Month)))
                      (Quarter_Item (Month)).Non_Scanner_View_Count :=
                      @ + Amount;
@@ -698,8 +698,8 @@
 From: Bob Duff
 Sent: Friday, January 8, 2016  7:52 PM
 
-> (1) Easy to lose the special case in a complex RHS expression. Even 
-> though @ is a "big" character, it's still only one character. It does 
+> (1) Easy to lose the special case in a complex RHS expression. Even
+> though @ is a "big" character, it's still only one character. It does
 > well in the normal case:
 >       Obj.I := @ + 1;
 > so we didn't worry about this too much.
@@ -707,12 +707,12 @@
 Right, I don't buy arguments of the form, "that feature would allow people to
 deliberately obfuscate".  If @ buried deep is confusing, then Don't Do That.
 
-> (2) A one character difference can transform an expression into 
+> (2) A one character difference can transform an expression into
 > something else legal that means something very different.
-> 
+>
 > This originally was raised with the proposal of AI12-0125-2:
 >      Obj:+1;     vs. Obj:=+1;
-> 
+>
 > But AI12-0125-3 has the same problem:
 >      Obj:=@+1;   vs. Obj:=+1;
 
@@ -726,13 +726,13 @@
 spaces.
 
 >    [X] := [] + 1;  --  A shorthand for X := X + 1;
-> 
->    [A(I)] := Integer'Max ([], 10); -- A shorthand for A(I) := 
+>
+>    [A(I)] := Integer'Max ([], 10); -- A shorthand for A(I) :=
 > Integer'Max (A(I), 10);
-> 
-> The square brackets around the LHS keys the reader that (A) this is an 
+>
+> The square brackets around the LHS keys the reader that (A) this is an
 > assignment with a shorthand; (B) the text in brackets is a complete context.
-> Thus the use of the target_name shorthand does not harm readability in 
+> Thus the use of the target_name shorthand does not harm readability in
 > that way.
 
 The idea of marking the LHS somehow as "this will have one or more
@@ -762,18 +762,18 @@
 Sent: Friday, January 8, 2016  8:05 PM
 
 ...
-> The idea of marking the LHS somehow as "this will have one or 
-> more shorthands", and then using the shorthands, seems like a 
+> The idea of marking the LHS somehow as "this will have one or
+> more shorthands", and then using the shorthands, seems like a
 > great idea.
 > But I really, REALLY don't like using square brackets for that.
-> To me, [X] should be a one-element aggregate, and [] should 
-> mean "(null record)" or "(1..0 => junk_value)" or whatever 
+> To me, [X] should be a one-element aggregate, and [] should
+> mean "(null record)" or "(1..0 => junk_value)" or whatever
 > obfuscation Ada currently requires.
 
 (others => <>)   ;-)
- 
-> I like your semantics, but unless you can come up with a 
-> better syntax, I say squelch it.  (Sorry, I can't think of 
+
+> I like your semantics, but unless you can come up with a
+> better syntax, I say squelch it.  (Sorry, I can't think of
 > better syntax at the
 > moment.)
 
@@ -832,7 +832,7 @@
 From: Gary Dismukes
 Sent: Monday, January 11, 2016  3:36 PM
 
-Right, that's the intention.  There are only minor restrictions.  It's a 
+Right, that's the intention.  There are only minor restrictions.  It's a
 onstant view, so it can't be used as an actual for an out parameter in a
 function call, and the left-hand side can't be overloaded, but other than
 those it can be used generally on the rhs.
@@ -843,13 +843,13 @@
 Sent: Thursday, January 14, 2016  4:33 AM
 
 >    [X] := [] + 1;  --  A shorthand for X := X + 1;
-> 
->    [A(I)] := Integer'Max ([], 10); -- A shorthand for A(I) := 
+>
+>    [A(I)] := Integer'Max ([], 10); -- A shorthand for A(I) :=
 > Integer'Max (A(I), 10);
-> 
-> The square brackets around the LHS keys the reader that (A) this is an 
+>
+> The square brackets around the LHS keys the reader that (A) this is an
 > assignment with a shorthand; (B) the text in brackets is a complete context.
-> Thus the use of the target_name shorthand does not harm readability in 
+> Thus the use of the target_name shorthand does not harm readability in
 > that way.
 
 I like the idea of having a more explicit syntax like this one better than
@@ -910,7 +910,7 @@
 From: Randy Brukardt
 Sent: Thursday, January 15, 2016  12:33 PM
 
-> Maybe we are getting hung up on having different characters for the 
+> Maybe we are getting hung up on having different characters for the
 > left and right bookmark.
 
 We're not "hung up" on it. My idea was that the characters used had to look
@@ -921,15 +921,15 @@
 > Some good options might
 > involve using the same character for both.  eg. Maybe the colon?
 > as in;
-> 
+>
 > :X: := :: + 1;
 
 (1) I don't think :: looks like brackets; I think of colon as a separator.
 (2) I think using colons for this would make error correction harder.
 
-> I like this also better if it can be more generally useful. 
-> Rather than say its always a substitution for the lhs of an 
-> assignment, this might allow for substituting an expression that 
+> I like this also better if it can be more generally useful.
+> Rather than say its always a substitution for the lhs of an
+> assignment, this might allow for substituting an expression that
 > occurs earlier on the rhs.
 
 I thought about that as a possibility, but I rejected it as pretty much
@@ -956,16 +956,16 @@
 From: Randy Brukardt
 Sent: Thursday, January 14, 2016  12:42 PM
 
-> One interesting point is that currently "()" is illegal in 
-> Ada, as is the use of parens around the LHS of an assignment. 
+> One interesting point is that currently "()" is illegal in
+> Ada, as is the use of parens around the LHS of an assignment.
 >  So we could propose the following:
-> 
+>
 > (This.Is.A.Long.Name[I]) := () + 1;
-> 
-> This avoids introducing a new special character.  I agree 
-> with Bob that if we are going to start using '[' and ']' 
-> there are a lot more interesting things we should do with it, 
-> and it will confuse the heck out of people coming from C if 
+>
+> This avoids introducing a new special character.  I agree
+> with Bob that if we are going to start using '[' and ']'
+> there are a lot more interesting things we should do with it,
+> and it will confuse the heck out of people coming from C if
 > you can't use [] for indexing.
 
 That seems like an advantage to me. ;-) Seriously, the more different two
@@ -973,7 +973,7 @@
 difficulty I ever had was in the early days of Janus/Ada when the compiler
 was still written in Pascal; keeping straight the rules for both languages
 was a nightmare.) The fewer syntax similarities with C the better (after
-all, that's the reason we're discussing this proposal). 
+all, that's the reason we're discussing this proposal).
 
 The reason that we ultimately went away from <<>> to using @ was that some
 people were concerned about confusion with other uses of the characters,
@@ -1024,7 +1024,7 @@
 
 > I kind of like "()".  Any comments on that?
 
-I don't much like it, although I like it more that "[]".  I don't see any 
+I don't much like it, although I like it more that "[]".  I don't see any
 compelling reason to mark the lhs at all.  Randy gave two reasons, but they
 seem pretty weak -- reasonable whitespace solves them.
 
@@ -1078,7 +1078,7 @@
 
 Another couple of tweaks to Tuckers suggestion...
 
-In for loops we have  syntax  to allow 
+In for loops we have  syntax  to allow
      for I in 1 .. 10 loop
 
 the ".." can be viewed as a substitution for all the numbers between 1 and 10
@@ -1104,7 +1104,7 @@
 This might provide a further visual clue about what the (..) is referring to,
 plus it has the advantage that if we ever decided down the road to allow
 similar substitutions on the RHS, we could add that to the language in a
-compatible manner. 
+compatible manner.
 
 eg.   Answer := (. Really_Really_Long_Name(I) .) * 2 + (..) mod 2;
 
@@ -1148,7 +1148,7 @@
 a comment and then deleting it is wasted programming time.)
 
 > The main advantage of "()" is that it avoids adding another special
-> character to Ada's lexical character set. 
+> character to Ada's lexical character set.
 
 We discussed that in Bennington in the context of whether to use "<<>>" (a
 better choice, IMHO, if we're sticking with existing characters only) or to
@@ -1184,7 +1184,7 @@
 Sent: Friday, January 15, 2016  1:14 PM
 
 I think that Brad's proposal is the best so far, but no mandatory brackets
-on the left. 
+on the left.
 
 ****************************************************************
 
@@ -1220,14 +1220,14 @@
 From: Brad Moore
 Sent: Friday, January 15, 2016  2:57 PM
 
-> Though I quite like the argument for (..) that .. implies 
-> substitution, remember that we would probably have gone for <> due to 
-> is implication of substitution if it wasnít already taken for other 
+> Though I quite like the argument for (..) that .. implies
+> substitution, remember that we would probably have gone for <> due to
+> is implication of substitution if it wasnít already taken for other
 > purposes.
-> 
-> But I still donít like the idea of bracketing the LHS, itís just 
+>
+> But I still donít like the idea of bracketing the LHS, itís just
 > clutter, double brackets such as the )) in
-> 
+>
 > (Really_Really_Long_Name(I)) := (..) + 1; just cause confusion.
 
 We could say that the LHS parens are redundant and thus are optional and can
@@ -1243,9 +1243,9 @@
 Sent: Friday, January 15, 2016  3:08 PM
 
 > How about three dots rather than two? Thus
-> 
+>
 > Sow.piglets := (...) + 1;
-> 
+>
 > I rather like that.
 
 That would be the first lexeme with three characters (or five, depending on
@@ -1268,7 +1268,7 @@
 From: Randy Brukardt
 Sent: Friday, January 15, 2016  3:10 PM
 
-> Or we could go further and say that since the LHS parens are always 
+> Or we could go further and say that since the LHS parens are always
 > redundant, they are not allowed and illegal.
 
 The LHS is a name, parens are not allowed now. So we don't have to say
@@ -1279,10 +1279,10 @@
 From: Bob Duff
 Sent: Friday, January 15, 2016  4:02 PM
 
-> If I woke up from the rip van winkle effect, or just as someone 
-> completely new to the language, I think I would notice both the parens 
-> on the LHS, and the empty parens, and would probably be able figure 
-> out that the empty parens are referring to the text in the LHS 
+> If I woke up from the rip van winkle effect, or just as someone
+> completely new to the language, I think I would notice both the parens
+> on the LHS, and the empty parens, and would probably be able figure
+> out that the empty parens are referring to the text in the LHS
 > parents.
 
 Really?  If I woke up from the winkle effect, and saw:
@@ -1354,7 +1354,7 @@
 Sent: Friday, January 15, 2016  4:28 PM
 
 > > And finally, I prefer the concise syntax of @.
-> 
+>
 > Still.  ;-)
 
 What he said. :-)
@@ -1386,7 +1386,7 @@
 
         LHS renames Data.Total.Hit_Count := LHS + Amount;
         LHS renames Quarter_Item_Data (Data.By_Month (Year, Quarter_Num (Month)))
-             (Quarter_Item (Month)).Hit_Count := LHS + Amount;       
+             (Quarter_Item (Month)).Hit_Count := LHS + Amount;
 
 It's pretty clear to me which of these is the most readable. But I'll let you
 draw your own conclusions (it's @ :-).
@@ -1396,7 +1396,7 @@
 From: Bob Duff
 Sent: Friday, January 15, 2016  4:32 PM
 
-> The main advantage of "()" is that it avoids adding another special 
+> The main advantage of "()" is that it avoids adding another special
 > character to Ada's lexical character set.
 
 I see that as a DISadvantage -- creating new notations is better than creating
@@ -1408,8 +1408,8 @@
 the left-hand side with any syntax at all, just because you want to use this
 new feature.
 
->..."@" smacks a bit of a C-like construct, where there are a zillion  
->special characters like !, ~, ^, &, %, ... making the code look a bit 
+>..."@" smacks a bit of a C-like construct, where there are a zillion
+>special characters like !, ~, ^, &, %, ... making the code look a bit
 >like chicken  scratchings.
 
 Yeah, I guess.  I prefer "not" over "!" and "and" over "&&" and
@@ -1421,7 +1421,7 @@
 we're stuck with some sort of weird symbol(s), and we should choose something
 not easily mistaken for something else, and something concise.
 
->...A construct like "()" seems more nearly English, and generally feels 
+>...A construct like "()" seems more nearly English, and generally feels
 >more consistent with the rest of Ada syntax.
 
 To me, it feels more overloaded/confused with existing Ada syntax.
@@ -1478,26 +1478,26 @@
 about a new keyword conflicting with names in user code. Why not consider
 using "ditto" as the keyword. Hence Some_Really_Long_Name := ditto + 1;  Every
 English speaker recognizes what "ditto" means, so brain interpretation is
-instantaneous. 
+instantaneous.
 
 ****************************************************************
 
 From: Randy Brukardt
 Sent: Friday, January 15, 2016  6:13 PM
 
-... 
-> >..."@" smacks a bit of a C-like construct, where there are a zillion 
-> >special characters like !, ~, ^, &, %, ... making the code look a bit 
+...
+> >..."@" smacks a bit of a C-like construct, where there are a zillion
+> >special characters like !, ~, ^, &, %, ... making the code look a bit
 > >like chicken  scratchings.
-> 
-> Yeah, I guess.  I prefer "not" over "!" and "and" over "&&" 
+>
+> Yeah, I guess.  I prefer "not" over "!" and "and" over "&&"
 > and "Shift_Left(...)" over "... << ...".
-> 
-> For the same reason, I'd prefer a keyword instead of @.  But I thought 
-> we discussed that at the last meeting, and we were worried that WG9 
+>
+> For the same reason, I'd prefer a keyword instead of @.  But I thought
+> we discussed that at the last meeting, and we were worried that WG9
 > can't stomach non-reserved keywords, and I
-> (we?) can't stomach an incompatibility here.  So we're stuck with some 
-> sort of weird symbol(s), and we should choose something not easily 
+> (we?) can't stomach an incompatibility here.  So we're stuck with some
+> sort of weird symbol(s), and we should choose something not easily
 > mistaken for something else, and something concise.
 
 I don't view it as "stuck". I think a keyword would be worse than a character
@@ -1538,9 +1538,9 @@
 ****************************************************************
 
 From: Stephen Michell
-Sent: Friday, January 15, 2016  7:05 PM	
+Sent: Friday, January 15, 2016  7:05 PM
 
-I was proposing ditto as a reserved keyword. 
+I was proposing ditto as a reserved keyword.
 
 ****************************************************************
 
@@ -1548,7 +1548,7 @@
 Sent: Friday, January 15, 2016  7:53 PM
 
 No need to keep complaining about "()". I prefer "(..)" which I believe is
-visible, short, and nicely Ada-ish. 
+visible, short, and nicely Ada-ish.
 
 ****************************************************************
 
@@ -1556,8 +1556,8 @@
 Sent: Friday, January 15, 2016  9:19 PM
 
 ...
-> By the way, nobody has explained very well why one should be required 
-> to mark the left-hand side with any syntax at all, just because you 
+> By the way, nobody has explained very well why one should be required
+> to mark the left-hand side with any syntax at all, just because you
 > want to use this new feature.
 
 I am totally OK with dropping the LHS parens, and I sense that others are as
@@ -1580,39 +1580,39 @@
 
 Here's a relevant quote from para 7 of page 1 of the RM. (Design Goals)
 
-"The need for languages that promote reliability and simplify 
-maintenance is well established. Hence emphasis was placed on program 
+"The need for languages that promote reliability and simplify
+maintenance is well established. Hence emphasis was placed on program
 readability over ease of writing."
 
   ...   -- No pun intended...  (OK maybe that one)
 
-"Furthermore, error-prone notations have been avoided, and the syntax of 
-the language avoids the use of encoded forms in favor of more 
+"Furthermore, error-prone notations have been avoided, and the syntax of
+the language avoids the use of encoded forms in favor of more
 English-like constructs. "
 
-This suggests that it should be unimportant whether one has to type 4 
-characters instead of 1, and @ is definitely an encoded form, so it 
+This suggests that it should be unimportant whether one has to type 4
+characters instead of 1, and @ is definitely an encoded form, so it
 should be avoided.
 
-The @ character has no association with text replacement, so it is 
-entirely a cryptic notation, which seems to not be in the spirit of the 
+The @ character has no association with text replacement, so it is
+entirely a cryptic notation, which seems to not be in the spirit of the
 Ada design goals.
 
-I'd prefer to see something that conveys meaning, ideally an English 
-word, such as ditto, like Steve suggests, but if new keywords are 
-problematic, the next best thing would be some symbolic representation 
+I'd prefer to see something that conveys meaning, ideally an English
+word, such as ditto, like Steve suggests, but if new keywords are
+problematic, the next best thing would be some symbolic representation
 that has similar meaning.
 
-We've been discussing ..., since it is a symbolic representation of 
-ellipses which indicate an omission, but ditto seems closer to what we 
-are trying to convey since it means that the text above(~before) is 
+We've been discussing ..., since it is a symbolic representation of
+ellipses which indicate an omission, but ditto seems closer to what we
+are trying to convey since it means that the text above(~before) is
 repeated.
 
-The symbolic representation of ditto of course is ", but I recognize 
-there would be confusion and parsing problems if we used the double 
+The symbolic representation of ditto of course is ", but I recognize
+there would be confusion and parsing problems if we used the double
 quote character alone.
 
-One could however look at the convention used Polish, Czech, and 
+One could however look at the convention used Polish, Czech, and
 Austrian German, which is to use the ditto mark surrounded by em-dashes.
 
 ie.  -"-
@@ -1735,27 +1735,27 @@
 From: Bob Duff
 Sent: Sunday, January 17, 2016  2:53 PM
 
-> I am totally OK with dropping the LHS parens, and I sense that others 
+> I am totally OK with dropping the LHS parens, and I sense that others
 > are as well. I agree that they are unnecessary and just add clutter.
 
 OK, sounds good.
 
-> Here's a relevant quote from para 7 of page 1 of the RM. (Design 
+> Here's a relevant quote from para 7 of page 1 of the RM. (Design
 > Goals)
-> 
-> "The need for languages that promote reliability and simplify 
-> maintenance is well established. Hence emphasis was placed on program 
+>
+> "The need for languages that promote reliability and simplify
+> maintenance is well established. Hence emphasis was placed on program
 > readability over ease of writing."
-> 
+>
 >   ...   -- No pun intended...  (OK maybe that one)
 
 It took me a while to understand what pun you were referring to!  ;-)
 
-> "Furthermore, error-prone notations have been avoided, and the syntax 
-> of the language avoids the use of encoded forms in favor of more 
+> "Furthermore, error-prone notations have been avoided, and the syntax
+> of the language avoids the use of encoded forms in favor of more
 > English-like constructs. "
 
-Well, I'm sure we all agree with the above platitudes.  But the only way to 
+Well, I'm sure we all agree with the above platitudes.  But the only way to
 be English-like would be a keyword.  You can't use the above to argue for @
 over (..) or vice versa -- ALL of the non-keyword suggestions are not
 English, and have no intuitive meaning, so people will need to memorize what
@@ -1773,14 +1773,14 @@
 I feel pretty strongly about that; "..." is hugely useful in discussions
 about programming languages.
 
-> This suggests that it should be unimportant whether one has to type 4 
-> characters instead of 1, and @ is definitely an encoded form, so it 
+> This suggests that it should be unimportant whether one has to type 4
+> characters instead of 1, and @ is definitely an encoded form, so it
 > should be avoided.
 
 It's not typing; the conciseness is for readability.
 
 > So this would give us...
-> 
+>
 > Really_Really_Long_Name(I) := -"- + 1;
 
 So the compiler has to look ahead to distinguish the above from:
@@ -1802,11 +1802,11 @@
 From: Bob Duff
 Sent: Sunday, January 17, 2016  2:54 PM
 
-> What I believe you need to specify somewhere is that side-effects have 
+> What I believe you need to specify somewhere is that side-effects have
 > no influence on whatever the repetition is supposed to designate.
-> 
+>
 > That is (for the () proposal), in
-> (A(I)) := change_the_I_or_the_access_A(42) * (); the semantics are 
+> (A(I)) := change_the_I_or_the_access_A(42) * (); the semantics are
 > well-defined. Or do you want textual macros?(Uggh. I hope not.)
 
 Right, I'm pretty sure everybody agrees we don't want macro-expansion
@@ -1829,20 +1829,20 @@
 
 I think everybody else wanted to obfuscate.  ;-) ;-)
 
-> This may have already been said in an early message but all the 
+> This may have already been said in an early message but all the
 > discussion over syntax should not loose the thought.
-> 
+>
 > -----------------
-> A few more concerns about the reuse of existing operators and about 
+> A few more concerns about the reuse of existing operators and about
 > the marking of the LHS.
-> If (lhs) can only be applied to the entire LHS, is is useless clutter, 
-> plus this already noted "oops an illegal paranthesized expression LHS" 
+> If (lhs) can only be applied to the entire LHS, is is useless clutter,
+> plus this already noted "oops an illegal paranthesized expression LHS"
 > - complication to semantic rules interacting with syntax.
-> 
+>
 > If it can be applied more broadly, what does
 > A(I) := 42 * ();
 > mean? Presumably illegal, since the () are the indexing op?
-> 
+>
 > What about
 > A(4*(I)) := 42 * ();
 > A((I)) := ();
@@ -1851,13 +1851,13 @@
 Right, all good reasons to avoid overgeneralizing this.
 
 > ----------
-> 
+>
 > Of all the existing proposals, I like @ or ?.
 > I hate "()" - too small a hamming distance to other programs.
 > (...) is read as "to be filled in later"
 > (.) is better but looks like Sumerian writing :-) .
-> 
-> And I am dead set against marking the LHS, if only full LHS can be 
+>
+> And I am dead set against marking the LHS, if only full LHS can be
 > marked.
 
 I'm against marking the LHS, dot.
@@ -1867,16 +1867,16 @@
 From: Tucker Taft
 Sent: Sunday, January 17, 2016  6:10 PM
 
-> What I believe you need to specify somewhere is that side-effects have 
+> What I believe you need to specify somewhere is that side-effects have
 > no influence on whatever the repetition is supposed to designate.
 
 The semantics are of a rename of the LHS.
 
 > That is (for the () proposal), in
-> (A(I)) := change_the_I_or_the_access_A(42) * (); the semantics are 
+> (A(I)) := change_the_I_or_the_access_A(42) * (); the semantics are
 > well-defined. Or do you want textual macros?(Uggh. I hope not.)
 >
-> This may have already been said in an early message but all the 
+> This may have already been said in an early message but all the
 > discussion over syntax should not loose the thought.
 
 I believe it was captured in the original AIs.
@@ -1896,33 +1896,33 @@
 Sent: Sunday, January 17, 2016  2:50 PM
 
 > If I got some Ada code reading,
-> 
+>
 >         Data.Total.Hit_Count := @ + Amount;
-> 
-> I'd know there is something to figure out, and I'd go look in an Ada 
+>
+> I'd know there is something to figure out, and I'd go look in an Ada
 > manual or ask a question on comp.lang.ada or stackoverflow.
-> 
+>
 > If I got instead:
-> 
+>
 >        Data.Total.Hit_Count := ditto + Amount;
-> 
-> (using Steve's suggestion), I'd probably waste a lot of time trying to 
+>
+> (using Steve's suggestion), I'd probably waste a lot of time trying to
 > figure out where "ditto" is defined.
-> 
-> I suppose if you are using an editor that colors or boldfaces 
-> keywords, it would be less of an issue, but not everyone uses those 
-> (by choice or requirements). Note that we don't have that in our code 
+>
+> I suppose if you are using an editor that colors or boldfaces
+> keywords, it would be less of an issue, but not everyone uses those
+> (by choice or requirements). Note that we don't have that in our code
 > examples here.
 
 I don't like those color-izing editors.  But Rip should know that keywords are
 typically in lower case.  ;-)
 
-> Additionally, I don't see what "non-reserved keywords" has to do with 
-> this case. This isn't like "some", that only is used in a single 
-> context where no identifier can be used. These appear in arbitrary 
-> expressions. And we surely couldn't allow adding a declaration for 
-> "ditto" to change the meaning of assignments that just happen to be in 
-> scope. (And we couldn't just ignore such a declaration, either, that 
+> Additionally, I don't see what "non-reserved keywords" has to do with
+> this case. This isn't like "some", that only is used in a single
+> context where no identifier can be used. These appear in arbitrary
+> expressions. And we surely couldn't allow adding a declaration for
+> "ditto" to change the meaning of assignments that just happen to be in
+> scope. (And we couldn't just ignore such a declaration, either, that
 > would be pure evil.) So, I don't see how we could avoid having a keyword
 > used in this context be fully reserved.
 
@@ -1939,8 +1939,8 @@
 Anyway, if nobody is seriously proposing a keyword (reserved or not), we don't
 need to settle these issues.
 
-> Anyway, I think I prefer this to be lexically distinct from anything 
-> that might appear in an Ada 2012 expression. And conciseness is 
+> Anyway, I think I prefer this to be lexically distinct from anything
+> that might appear in an Ada 2012 expression. And conciseness is
 > important, thus @ is still leading in my mind.
 
 OK with me.
@@ -1955,7 +1955,7 @@
 such a specialized word in English that I suspect that it would be used in
 names of functions, types, or objects names. The fact that it is lowercase and
 bolded or coloured in many editors would give a strong clue that it is
-reserved. 
+reserved.
 
 I am against using specialized symbols such as @ or (). Ada almost never uses
 symbols that are not words or mathematical symbols. It is very much out of
@@ -1966,7 +1966,7 @@
 From: John Barnes
 Sent: Monday, January 18, 2016  2:04 AM
 
-The key thing in favour of @ for me is that it stands out like a sore thumb. 
+The key thing in favour of @ for me is that it stands out like a sore thumb.
 I hate () because it looks so much like zero or o.
 
 Let's vote.
@@ -2006,14 +2006,14 @@
 From: Randy Brukardt
 Sent: Monday, January 18, 2016  3:56 PM
 
-> What I believe you need to specify somewhere is that side-effects have 
+> What I believe you need to specify somewhere is that side-effects have
 > no influence on whatever the repetition is supposed to designate.
 
 We discussed that extensively in Bennington; all of the proposals nail down
 the semantics carefully. (See the current draft of AI12-0125-3 specifically).
 
 The only real open issue (other than editorial wording changes) is the actual
-syntax in question. Which *everyone* has an opinion on. 
+syntax in question. Which *everyone* has an opinion on.
 
 ****************************************************************
 
@@ -2022,12 +2022,12 @@
 
 ...
 > At the meeting, people suggested wording via various equivalences.
-> I suggested using the kind of wording that you'd use to explain it to 
+> I suggested using the kind of wording that you'd use to explain it to
 > a normal person:
-> 
+>
 >     @ denotes the value of the left-hand side, but the left-hand side is
 >     evaluated only once.
-> 
+>
 > I think everybody else wanted to obfuscate.  ;-) ;-)
 
 Everyone else wants preciseness. We want it obvious how to answer questions
@@ -2046,22 +2046,22 @@
 Sent: Monday, January 18, 2016  4:13 PM
 
 ...
-> > Additionally, I don't see what "non-reserved keywords" has to do 
-> > with this case. This isn't like "some", that only is used in a 
-> > single context where no identifier can be used. These appear in 
-> > arbitrary expressions. And we surely couldn't allow adding a 
-> > declaration for "ditto" to change the meaning of assignments that 
-> > just happen to be in scope. (And we couldn't just ignore such a 
-> > declaration, either, that would be pure evil.) So, I don't see how 
+> > Additionally, I don't see what "non-reserved keywords" has to do
+> > with this case. This isn't like "some", that only is used in a
+> > single context where no identifier can be used. These appear in
+> > arbitrary expressions. And we surely couldn't allow adding a
+> > declaration for "ditto" to change the meaning of assignments that
+> > just happen to be in scope. (And we couldn't just ignore such a
+> > declaration, either, that would be pure evil.) So, I don't see how
 > > we could avoid having a keyword used in this context be fully reserved.
-> 
-> Easy:  If the compiler sees a declaration of "ditto", it gives a 
-> diagnostic message.  (Yet another example where requiring messages is 
-> beneficial.)  Within the scope of that decl, "ditto" refers to the 
-> declaration; it's not the keyword.  I guess it should warn on every 
+>
+> Easy:  If the compiler sees a declaration of "ditto", it gives a
+> diagnostic message.  (Yet another example where requiring messages is
+> beneficial.)  Within the scope of that decl, "ditto" refers to the
+> declaration; it's not the keyword.  I guess it should warn on every
 > such USE of ditto as well.
-> 
-> In other words, it's a preference rule.  And preference rules are 
+>
+> In other words, it's a preference rule.  And preference rules are
 > evil, so we want diagnostic messages.
 
 So let me get this straight: in order to avoid making it reserved, you want
@@ -2079,10 +2079,10 @@
 appear somewhere a name can, the only possibility is confusion, no matter what
 rules are adopted.
 
-> BTW, I don't much like "ditto".  I'd call it "it".  Or "lhs" 
+> BTW, I don't much like "ditto".  I'd call it "it".  Or "lhs"
 > is tolerable.
-> 
-> Anyway, if nobody is seriously proposing a keyword (reserved or not), 
+>
+> Anyway, if nobody is seriously proposing a keyword (reserved or not),
 > we don't need to settle these issues.
 
 Steve Michell has seriously proposed "ditto". Twice. I guess since he's not an
@@ -2098,7 +2098,7 @@
 
 > That sounds like a recipe for indecision to me.
 
-I agree. I don't think the exact syntax matters all that much; whatever we 
+I agree. I don't think the exact syntax matters all that much; whatever we
 choose, everyone will get used to.
 
 So long as we don't chose anything severely bad: whatever we chose should not
@@ -2115,12 +2115,12 @@
 Sent: Monday, January 18, 2016  4:25 PM
 
 > I have a question about the (..) idea.
-> 
-> If we have given up the idea of bracketing the lhs, is there still 
+>
+> If we have given up the idea of bracketing the lhs, is there still
 > value in having the parens around ".."?
-> 
+>
 > Otherwise, I think it is an improvement to just use .., as in.
-> 
+>
 > Really_Long_Name := .. + 1;
 
 I don't think this works. Ada users expect ".." to mean a range. And ranges
@@ -2161,7 +2161,7 @@
 Sent: Monday, January 18, 2016  4:38 PM
 
 > >... And what is getting evaluated? The  LHS isn't a value at all.
-> 
+>
 > The LHS is a name, and names are evaluated.
 > See 5.2(7).
 
@@ -2175,7 +2175,7 @@
 From: Bob Duff
 Sent: Monday, January 18, 2016  4:58 PM
 
-> Sure, but your wording talked about "the value of the LHS" or 
+> Sure, but your wording talked about "the value of the LHS" or
 > something like that.
 
 No, it didn't.  It talked about "the left-hand side".  But I guess you're
@@ -2196,7 +2196,7 @@
 From: Bob Duff
 Sent: Monday, January 18, 2016  5:45 PM
 
-> So let me get this straight: in order to avoid making it reserved, you 
+> So let me get this straight: in order to avoid making it reserved, you
 > want to require every use of the keyword as an identifier to have a soft error?
 
 Yes.  Or maybe just every declaration.
@@ -2218,8 +2218,8 @@
 
 Ask Jeff.  Same reason as with "interface".
 
->...Plus you'd still have the danger of someone making  a compiler which 
->turns these warnings off (Robert used to threaten that  about GNAT and 
+>...Plus you'd still have the danger of someone making  a compiler which
+>turns these warnings off (Robert used to threaten that  about GNAT and
 >soft errors) and then the meaning changing silently.
 
 I've no idea what you mean.  If the RM requires a diagnostic message, then
@@ -2228,9 +2228,9 @@
 and of course compilers can have switches that turn messages on and off.  So
 what?
 
-> I mean, this is the sort of thinking that gives non-reserved keywords 
-> a bad name. In the cases of "overriding" and "some", the keyword can 
-> only appear syntactically where no identifier is allowed, so there can 
+> I mean, this is the sort of thinking that gives non-reserved keywords
+> a bad name. In the cases of "overriding" and "some", the keyword can
+> only appear syntactically where no identifier is allowed, so there can
 > be no confusion and no need for any sort of warning.
 
 On the contrary, if nonreserved keywords existed, I think they deserve a
@@ -2239,18 +2239,18 @@
 in the syntax.  I would think soft errors would make those people more
 comfortable with the idea.
 
->...So those make sense (even though we've  never been able to convince 
->enough people of that value). If the keyword can  appear  somewhere a 
->name can, the only possibility is confusion, no matter  what rules are 
+>...So those make sense (even though we've  never been able to convince
+>enough people of that value). If the keyword can  appear  somewhere a
+>name can, the only possibility is confusion, no matter  what rules are
 >adopted.
-> 
+>
 > > BTW, I don't much like "ditto".  I'd call it "it".  Or "lhs"
 > > is tolerable.
 > >
-> > Anyway, if nobody is seriously proposing a keyword (reserved or 
+> > Anyway, if nobody is seriously proposing a keyword (reserved or
 > > not), we don't need to settle these issues.
-> 
-> Steve Michell has seriously proposed "ditto". Twice. I guess since 
+>
+> Steve Michell has seriously proposed "ditto". Twice. I guess since
 > he's not an ARG member, he doesn't count?
 
 I can't keep track of who proposed what, nor how serious they are.
@@ -2264,13 +2264,13 @@
 Sent: Monday, January 18, 2016  6:23 PM
 
 > > Which you'd have to suppress to continue?
-> 
+>
 > No.  The whole point of soft errors is to give people a choice:
-> If it's expensive to modify code in your project, you can choose to 
-> ignore the errors, and your program will still mean what it used to 
-> mean.  That's "compatibility".  On the other hand, if you want to 
-> maximize readability, you can change all the uses of "Ditto" as an 
-> identifier to something else, and then start using "ditto" as a 
+> If it's expensive to modify code in your project, you can choose to
+> ignore the errors, and your program will still mean what it used to
+> mean.  That's "compatibility".  On the other hand, if you want to
+> maximize readability, you can change all the uses of "Ditto" as an
+> identifier to something else, and then start using "ditto" as a
 > keyword.
 
 That's what I meant by "Suppress". In Ada Standard terms, that's some sort
@@ -2284,10 +2284,10 @@
 
 And that's fine if it isn't confusing to readers. But this case (and I mean
 *specifically* this case) would be too confusing to readers.
- 
+
 > >...How is that any sort of advantage
 > > over having it reserved?
-> 
+>
 > Ask Jeff.  Same reason as with "interface".
 
 "Interface" is like "some" and "overriding" (if I was going to list all of
@@ -2298,14 +2298,14 @@
 agree with over-the-top arguments that *everything* ought to be done that way,
 even at the cost of pages of rules about soft errors and the like.
 
-> >...Plus you'd still have the danger of someone making  a compiler 
-> >which turns these warnings off (Robert used to threaten that about 
+> >...Plus you'd still have the danger of someone making  a compiler
+> >which turns these warnings off (Robert used to threaten that about
 > >GNAT and soft errors) and then the meaning changing silently.
-> 
-> I've no idea what you mean.  If the RM requires a diagnostic message, 
+>
+> I've no idea what you mean.  If the RM requires a diagnostic message,
 > then we can have an ACATS test that tests conformance with that rule.
-> And of course one can write a nonconforming implementation of 
-> not-quite-Ada, and of course compilers can have switches that turn 
+> And of course one can write a nonconforming implementation of
+> not-quite-Ada, and of course compilers can have switches that turn
 > messages on and off.  So what?
 
 The default for GNAT is the real defacto standard (sadly). When Robert
@@ -2320,15 +2320,15 @@
 the behavior when the error is suppressed or ignored or whatever it gets
 called.)
 
-> > I mean, this is the sort of thinking that gives non-reserved 
-> > keywords a bad name. In the cases of "overriding" and "some", the 
-> > keyword can only appear syntactically where no identifier is 
+> > I mean, this is the sort of thinking that gives non-reserved
+> > keywords a bad name. In the cases of "overriding" and "some", the
+> > keyword can only appear syntactically where no identifier is
 > > allowed, so there can be no confusion and no need for any sort of warning.
-> 
-> On the contrary, if nonreserved keywords existed, I think they deserve 
-> a warning.  And certainly the people who think nonreserved keywords 
-> are evil think that it's confusing to use a keyword as an identifier, 
-> no matter where in the syntax.  I would think soft errors would make 
+>
+> On the contrary, if nonreserved keywords existed, I think they deserve
+> a warning.  And certainly the people who think nonreserved keywords
+> are evil think that it's confusing to use a keyword as an identifier,
+> no matter where in the syntax.  I would think soft errors would make
 > those people more comfortable with the idea.
 
 This I completely disagree with - in part because "those people" are wrong,
@@ -2341,22 +2341,22 @@
 If there is a significant possible conflict, then the keywords should be
 reserved. Period.
 
-> >...So those make sense (even though we've  never been able to 
-> >convince enough people of that value). If the keyword can appear 
-> >somewhere a name can, the only possibility is confusion, no matter 
+> >...So those make sense (even though we've  never been able to
+> >convince enough people of that value). If the keyword can appear
+> >somewhere a name can, the only possibility is confusion, no matter
 > >what rules are adopted.
-> > 
+> >
 > > > BTW, I don't much like "ditto".  I'd call it "it".  Or "lhs"
 > > > is tolerable.
 > > >
-> > > Anyway, if nobody is seriously proposing a keyword (reserved or 
+> > > Anyway, if nobody is seriously proposing a keyword (reserved or
 > > > not), we don't need to settle these issues.
-> > 
-> > Steve Michell has seriously proposed "ditto". Twice. I guess since 
+> >
+> > Steve Michell has seriously proposed "ditto". Twice. I guess since
 > > he's not an ARG member, he doesn't count?
-> 
+>
 > I can't keep track of who proposed what, nor how serious they are.
-> I stand by my statement "IF (IF!) nobody is seriously proposing a 
+> I stand by my statement "IF (IF!) nobody is seriously proposing a
 > keyword (reserved or not), we don't need to settle these issues."
 > My statement doesn't say anything about who "counts".
 
@@ -2381,8 +2381,8 @@
 >> I hate "()" - too small a hamming distance to other programs.
 >> (...) is read as "to be filled in later"
 >> (.) is better but looks like Sumerian writing :-) .
-> 
-> And what about "(..)" suggested by Brad, and preferred by myself, and 
+>
+> And what about "(..)" suggested by Brad, and preferred by myself, and
 > I believe JP?
 
 Well, (..) and (...) share this "to be filled in later" problem. If I wrote on
@@ -2404,9 +2404,9 @@
 Sent: Tuesday, January 19, 2016  7:54 AM
 
 > For
-> 
+>
 > A(F(X)) := B(Y) * @;
-> 
+>
 > they'd ask what the funny symbol stands for.
 
 And nobody could justify using this...
@@ -2478,19 +2478,19 @@
 Sent: Tuesday, January 19, 2016  2:27 PM
 
 > > For
-> > 
+> >
 > > A(F(X)) := B(Y) * @;
-> > 
+> >
 > > they'd ask what the funny symbol stands for.
 > And nobody could justify using this...
-> 
-> In my courses, I generally make fun at C for chosing '!' for "not", 
-> saying that the only rationale for it was that it was not yet used on 
+>
+> In my courses, I generally make fun at C for chosing '!' for "not",
+> saying that the only rationale for it was that it was not yet used on
 > the keyboard. Now the same would apply to Ada...
 
 Really? You don't think any of us will ever come up with an appropriate rationale??
 
-> TBH, I'm afraid of very hostile reactions from the community. 
+> TBH, I'm afraid of very hostile reactions from the community.
 
 Possibly, but that's *not* going to be because of the choice of syntax.
 Ada's style is verbose, and this feature is all about our admitting that there
@@ -2608,9 +2608,9 @@
 From: Tucker Taft
 Sent: Friday, April 22, 2016  7:27 AM
 
-> Going back to Bennington, all of the following have been seriously 
-> proposed for this idea (the first three are the only ones that ever 
-> had any significant traction, the rest are in the order of occurrence 
+> Going back to Bennington, all of the following have been seriously
+> proposed for this idea (the first three are the only ones that ever
+> had any significant traction, the rest are in the order of occurrence
 > -- I used a full example of each so all of the nuances are visible):
 
 And my own personal favorite:
@@ -2693,7 +2693,7 @@
 
 > Examples
 >
->     Board(1, 1) := @ + 1;  -- An abbreviation for Board(1, 1) := 
+>     Board(1, 1) := @ + 1;  -- An abbreviation for Board(1, 1) :=
 > Board(1, 1)
 > + 1;
 >                            -- (Board is declared in 3.6.1).
@@ -2713,7 +2713,7 @@
 >                  Day   => (if @.Day = 1 then 28 else @.Day - 1));
 >        -- A target_name can be used multiple times and as a prefix if needed.
 >
-> If you have an improvement, please suggest it (there's not many 
+> If you have an improvement, please suggest it (there's not many
 > exciting types declared in chapter 3 or 4).
 
 Your "Long_Ago" example is interesting but inscrutable at the moment.
@@ -2724,15 +2724,15 @@
 Sent: Friday, August  5, 2016  3:22 PM
 
 ...
-> You need to add a comment here to explain the goal of this -- not 
+> You need to add a comment here to explain the goal of this -- not
 > obvious on a first reading.
 
 The goal is to provide an example - it doesn't do anything meaningful.
 
 ...
-> > If you have an improvement, please suggest it (there's not many 
+> > If you have an improvement, please suggest it (there's not many
 > > exciting types declared in chapter 3 or 4).
-> 
+>
 > Your "Long_Ago" example is interesting but inscrutable at the moment.
 
 There's a reason I asked for suggestions!! :-)
@@ -2801,13 +2801,13 @@
 From: Tucker Taft
 Sent: Friday, August  5, 2016  4:07 PM
 
-> ... Humm. Maybe "Subtract a month" is just complex enough for this 
-> problem, not so simple that there is a better solution and not so 
+> ... Humm. Maybe "Subtract a month" is just complex enough for this
+> problem, not so simple that there is a better solution and not so
 > complex as to drive one nuts. So maybe we should use:
 >
->      Last_Month := (Year  => (if @.Month = January then @.Year-1 else 
+>      Last_Month := (Year  => (if @.Month = January then @.Year-1 else
 > @.Year),
->                     Month => (if @.Month = January then December else 
+>                     Month => (if @.Month = January then December else
 > Month_Name'Pred(@.Month)),
 >                     Day   => @.Day);
 
@@ -2820,5 +2820,659 @@
 
 OK, I'll go with that (and the formatting was fine when I wrote it ;-),
 modulo comments from others.
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Tuesday, August  9, 2016  10:53 AM
+
+Of the examples, I prefer the last.
+Though to emphasise that @ can be short-hand for something quite complex, I'd
+put more complexity on the left hand side and less on the right, though still
+leaving the right hand side complex enough to have two @s, to still show that
+@ can be used multiple times:
+
+    Dates : array (1 .. 10) of Date := ...;
+    -- Previous month for each (wrapping round):
+    for Idx in Dates'Range loop
+       Dates(Idx).Month :=
+          (if @ = January then December else Month_Name'Pred(@));
+    end loop;
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, August  9, 2016  3:19 PM
+
+That suggestion doesn't cover my primary objective for the second example, which
+is to show that @ can be used as a name (specifically as a prefix to a selected
+component). I didn't realize that myself, and it seems important. Multiple uses
+was a secondary objective; I was happy to get both into a single example. (Along
+with showing a case where there is no chance of using something like :=+.)
+
+I could see using the last as it was originally written, or perhaps there is
+some other version that would cover all of the objectives.
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Wednesday, August 10, 2016  3:07 AM
+
+Ok, may be add "@ can be used as a name" as a comment.
+
+I still prefer the last example to the penultimate one, Last_Month seems too
+trivial for the left hand side, I'd like something with a bit of address
+calculation (i.e. Dates(Idx)).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, August 10, 2016  9:36 PM
+
+Since Tucker and Jeff seem to disagree on which example to use in the user
+Examples section of the RM for the new Target Name Symbol subclause, and it
+would be silly to reopen the AI for such a thing, I am asking for input from the
+entire ARG. (If that fails to find a resolution, I'll have to create an AI just
+for this question. Bah.)
+
+A reminder of the requirements for this RM example:
+  (1) The example has to be complete or depend on declarations earlier in the
+      RM;
+  (2) The example has to show the use of multiple target name symbols in a
+      single assignment;
+  (3) The example has to show the use of a target name symbol as a name (that
+      is, as a prefix rather than standing alone);
+  (4) The example should be something realistic and understandable.
+
+The current candidates:
+
+[A] (Tucker's choice)
+
+     Last_Month : Date := Yesterday; -- See 3.8
+     Last_Month := (Year  => (if @.Month = January then @.Year-1 else @.Year),
+                    Month => (if @.Month = January then December else Month_Name'Pred(@.Month)),
+                    Day   => @.Day);
+        -- A target_name can be used multiple times and as a prefix if needed.
+
+[B] (Jeff's choice)
+
+    Dates : array (1 .. 10) of Date := ...;  -- See 3.8
+    -- Subtract a month from each:
+    for Idx in Dates'Range loop
+       Dates(Idx) := (Year  => (if @.Month = January then @.Year-1 else @.Year),
+                      Month => (if @.Month = January then December else Month_Name'Pred(@.Month)),
+                      Day   => @.Day);
+        -- A target_name can be used multiple times and as a prefix if needed.
+    end loop;
+
+[C] (An alternative to B, using a declaration from 3.3.1 instead of the
+loop)
+
+    Dates : array (1 .. 10) of Date := ...;  -- See 3.8
+    Dates(Count) :=                          -- See 3.3.1
+          (Year  => (if @.Month = January then @.Year-1 else @.Year),
+           Month => (if @.Month = January then December else Month_Name'Pred(@.Month)),
+           Day   => @.Day);
+        -- A target_name can be used multiple times and as a prefix if needed.
+
+Please vote for one.
+
+P.S. If you want to suggest something different, please ensure that the
+suggestion meets (1) through (4) above.
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Thursday, August 11, 2016  4:15 AM
+
+C, preferably with the addition of comment     -- Subtract a month
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, August 11, 2016  7:52 AM
+
+I vote for C but change "1 .. 10" to "1 .. Max" (Max is declared in 3.3.2).
+It just seems weird to use a literal high bound and then use a non-literal index
+that comes out of thin air.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, August 11, 2016  8:37 AM
+
+C.
+
+And I agree with Jeff's and Tucker's comments.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Thursday, August 11, 2016  8:40 AM
+
+I think there is a problem with all of these examples, in that this blows up if
+the day number doesn't exist in the previous month, and doesn't handle leap
+years in the case of March 31.
+
+My vote is for [A], except change Last_Month to Start_Of_Last_Month,and then set
+the Day component to 1 on the assignment.
+
+To me this rules out the other choices because [A] is simpler, and the variable
+name describes the intent. Adding arrays and loops just obfuscates the example.
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Thursday, August 11, 2016  8:50 AM
+
+> ... Adding arrays and loops just obfuscates the example.
+
+I think it's important that the left hand side is something more than a simple
+variable.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Thursday, August 11, 2016  12:13 PM
+
+> I think there is a problem with all of these examples, in that this
+> blows up if the day number doesn't exist in the previous month, and doesn't handle leap years in the case of March 31.
+
+I agree. We don't want to showcase a sloppy example.
+
+Modulo that, I agree with Bob (i.e., C and agreement with Jeff's and Tucker's
+comments).
+
+****************************************************************
+
+From: Tullio Vardanega
+Sent: Thursday, August 11, 2016  1:37 PM
+
+I am for [C], after fixing the logic of the month decrement operation, which is
+currently broken.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, August 11, 2016  10:34 PM
+
+> > I think there is a problem with all of these examples, in that this
+> > blows up if the day number doesn't exist in the previous month, and
+> > doesn't handle leap years in the case of March 31.
+>
+> I agree. We don't want to showcase a sloppy example.
+>
+> Modulo that, I agree with Bob (i.e., C and agreement with Jeff's and
+> Tucker's comments).
+
+Huh? There is no way to repair C and both meet these additional requirements and
+meet the original requirements as well. As such, I withdraw the example
+completely -- I don't need the stress of this -- and -- in the absence of
+someone else proposing an example or examples that fulfill all of the
+requirements -- will ask that the entire AI be reconsidered. (If we can't find a
+realistic example, then the entire idea is dubious.)
+
+[I'll give a detailed breakdown of my thoughts below, but I need everyone to
+read the first part of this, so it will come later.]
+
+To repeat the requirements, as added to by various people here:
+
+  (1) [Std Reqmnt] The example has to be complete or depend on declarations
+      earlier in the RM;
+  (2) [Randy's intent] The example has to show the use of multiple target name
+      symbols in a single assignment;
+  (3) [Randy's intent] The example has to show the use of a target name symbol
+      as a name (that is, as a prefix rather than standing alone);
+  (4) [Tucker's addition] The example should be something realistic and
+      understandable;
+  (5) [Jeff's addition] The example's target name [LHS] needs to be something
+      complex (preferably some array indexing);
+  (6) [Brad's addition, 2nded by others] The example must not be "sloppy"; there
+      cannot be any corner cases unhandled.
+
+My problem is that no new subclause in the standard should exist without user
+examples. Since I'm apparently not allowed to have a reasonably simple example,
+my first inclination is to send the AI back the ARG until someone proposes it.
+However, doing so would cost me 4-6 hours of work since I've already put the AI
+into the draft Standard (2 hours to take it out -- it appears in 6 different
+chapters -- and 2-4 hours to put it back at some future date). That seems like a
+massive waste of my time and AdaCore's money. Similarly, making a separate AI
+for the examples would also cost several hours of work (I'd have to remove the
+examples from the draft Standard, and then presumably put some back at a future
+date, as well as create a draft AI).
+
+So, please propose an example (*not* using dates; it's obvious that we can never
+find an example using those that meets everyone's requirements); else I'm going
+to have to spend a lot of time doing busywork rather than anything valuable.
+
+====================================
+
+Here's my detailed rant on this topic. If you want to know why I'm both upset
+and at a loss as how to proceed, read on. If you are in a hurry, feel free to
+skip the below.
+
+[A] I'm certain that the date example cannot be reasonably fixed. The intended
+operation (find the same date in the previous month) is commonly used (well, at
+least the operation in the *next* month is), for instance in my financial
+software (find the default date for next month's statement; it's the same as the
+date of this month's statement.
+
+We could fix the major problem with a table of month-ends (I changed the example
+to next month to be more realistic):
+
+    Dates : array (1 .. Max) of Date := ...;  -- See 3.8 and 3.3.2
+    Month_End : array (Month_Name) of Natural := (January => 31, February => 28, ...);
+    -- Find the same date next month:
+    Dates(Count) :=                           -- See 3.3.1
+          (Year  => (if @.Month = December then @.Year+1 else @.Year),
+           Month => (if @.Month = December then December else Month_Name'Succ(@.Month)),
+           Day   => (if @.Month = December then @.Day else
+                        (if @.Day > Month_End(Month_Name'Succ(@.Month)) then
+                              Month_End(Month_Name'Succ(@.Month)) else @.Day)));
+        -- A target_name can be used multiple times and as a prefix if needed.
+
+However, leap years are essentially insolvable in a one-liner for this type, as
+the years run from 0 .. 4000 and the algorithm is different for years prior to
+1600. Moreover, this would make the example insanely complex, which defeats the
+purpose.
+
+The other realistic example, adding or subtracting a number of days (say 30),
+has all of the same problems, so I won't consider it further.
+
+[B] Brad's suggestion of making the date the first unconditionally fails any
+sort of "realistic" requirement. One could imagine (barely) doing that into a
+local variable, but not with an array as such an operation discards information.
+It's a non-starter for me.
+
+[C] The remaining problem here is that any "realistic" code would have Date as
+an ADT of some sort, so no one would ever write any of these examples as a
+one-liner anyway. If we're really going to insist on a "realistic" example that
+isn't "sloppy", we can't use dates at all.
+
+[D] I don't believe that many of the other examples in the RM meet (4) or (6).
+So I don't quite understand why this one is getting treated differently. For
+instance, calling the interface examples in 3.9.4 "realistic" and not "sloppy"
+is a stretch. (The next time I write a routine like Transfer will be my first --
+and what happens if the From queue doesn't have Number elements? How is that
+realistic?) And 3.9.4 is probably one of the better examples.
+
+[E] I briefly thought about trying some sort of matrix operation, but the array
+aggregate syntax is horrible enough to hide what's going on:
+
+    Tuple : Vector (1 .. 3) := ...;             -- See 3.6.
+    Matrix_List : array (1 .. Max) of Matrix(1 .. 3, 1 .. 3) := ...; -- See 3.3.2, 3.6.
+    -- Multiply by Tuple:
+    Matrix_List(Count) :=                -- See 3.3.1.
+        (1 => (1 => @(1,1)*Tuple(1), 2 => @(1,2)*Tuple(1), 3 => @(1,3)*Tuple(1)),
+         2 => (1 => @(2,1)*Tuple(2), 2 => @(2,2)*Tuple(2), 3 => @(2,3)*Tuple(2)),
+         3 => (1 => @(3,1)*Tuple(3), 2 => @(3,2)*Tuple(3), 3 => @(3,3)*Tuple(3)));
+        -- A target_name can be used multiple times and as a prefix if needed.
+
+This also has the same objection described in [C]: no one would ever write a
+matrix multiply this way. And it's "sloppy" in that doing an operation this way
+is likely to have numeric problems.
+
+Perhaps the new for syntax would help:
+
+    Tuple : Vector (1 .. 3) := ...;             -- See 3.6.
+    Matrix_List : array (1 .. Max) of Matrix(1 .. 3, 1 .. 3) := ...; -- See 3.3.2, 3.6.
+    -- Multiply by Tuple:
+    Matrix_List(Count) :=                -- See 3.3.1.
+        (for Row in 1 .. 3 => (for Col in 1 .. 3 => @(Row,Col)*Tuple(Col)));
+        -- A target_name can be used multiple times and as a prefix if needed.
+
+I suppose it does, but then we're depending on another AI (not great), and this
+does nothing to eliminate the [C] objections or the sloppiness. (I also can't
+figure out if I have Row and Col right, which doesn't bode well for using this
+in practice. :-)
+
+[F] I give up at this point. I'm fairly convinced that no example meeting (1) ..
+(6) exists. Indeed, even ignoring (1), I think that any case where I've written
+something like this in practice would have been described as "sloppy"; the
+operation should have been written as an ADT (in which case Jeff's requirement
+would not be met inside of the ADT operation, and there'd be nothing but a
+subprogram call at the point of use). Any example has to be either non-realistic
+or sloppy or both.
+
+[G] This latter realization is what makes me wonder about the wisdom of the
+feature at all (at least in this level of generality). It seems to mainly be
+valuable to support "sloppy" code, outside of single, stand-alone uses. Should
+this really be a name, or would it be better to make it a primary?? Do we really
+need to allow multiple uses? In the absence of an example, I'm starting to lean
+toward reconsideration.
+
+[H] Someone else needs to take a crack that this, because I'm not getting
+anywhere, but I am managing to waste vast amounts of time.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Friday, August 12, 2016  2:37 AM
+
+> Huh? There is no way to repair C and both meet these additional
+> requirements and meet the original requirements as well. As such, I
+> withdraw the example completely -- I don't need the stress of this --
+> and -- in the absence of someone else proposing an example or examples
+> that fulfill all of the requirements -- will ask that the entire AI be
+> reconsidered. (If we can't find a realistic example, then the entire
+> idea is dubious.)
+[rant deleted]
+
+Seems to me that if you call the variable "Due_Date", then it makes reasonable
+sense for it to be the first day of next month, and all the problems go away...
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, August 12, 2016  7:13 AM
+
+That seems like a clever idea.
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Friday, August 12, 2016  8:05 AM
+
+That seems reasonable.
+
+Or using the other type in 3.8, how about
+
+   My_Complex_Array : array (1 .. Max) of Complex; -- 3.3.2, 3.8
+
+begin
+
+   -- Square first element
+
+My_Complex_Array (1) := (Re => @.Re**2 - @.Im**2,
+                         Im => -2.0 * @.Re * @.Im);
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, August 12, 2016  9:55 AM
+
+Here is the example with JP's suggestion (and mine):
+
+
+     Due_Dates : array (1 .. Max) of Date := ...;  -- See 3.3.2, 3.8
+     Due_Dates(Count) :=                          -- See 3.3.1
+           (Year  => (if @.Month = December then @.Year+1 else @.Year),
+            Month => (if @.Month = December
+                      then January else Month_Name'Succ(@.Month)),
+            Day   => 1);  -- Adjust to be first of following month
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Friday, August 12, 2016  10:44 AM
+
+I like this version best for (C).
+
+Actually, I preferred the loop over Count with a reference that is completely
+disappointing when followed, but I saw from the polls that this is a minority
+opinion.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Friday, August 12, 2016  11:12 AM
+
+This works for me also.
+
+****************************************************************
+
+From: Tullio Vardanega
+Sent: Friday, August 12, 2016  1:25 PM
+
+I am also happy with this version.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, August 12, 2016  8:06 PM
+
+> >> ... Seems to me that if you call the variable "Due_Date", then it
+> >> makes reasonable sense for it to be the first day of next month,
+> >> and all the problems go away...
+> >
+> > That seems like a clever idea.
+
+I find it at least an unrealistic as the earlier ideas. And this basic idea
+(Brad's, originally) has made me quite upset; I had a lot of trouble getting to
+sleep last night.
+
+> Here is the example with JP's suggestion (and mine):
+>
+>
+>      Due_Dates : array (1 .. Max) of Date := ...;  -- See 3.3.2, 3.8
+>      Due_Dates(Count) :=                          -- See 3.3.1
+>            (Year  => (if @.Month = December then @.Year+1 else @.Year),
+>             Month => (if @.Month = December
+>                       then January else Month_Name'Succ(@.Month)),
+>             Day   => 1);  -- Adjust to be first of following month
+
+We'll use that over my dead body. It's far less realistic than the earlier
+ideas, and at least as sloppy.
+
+I've spent quite a bit of the time since J-P originally posted his idea figuring
+out precisely why this particular idea has this effect on me. I think I've
+figured it out well enough, but better yet I've figured out a better example
+which avoids the worst of the problems.
+
+[A] My original thought was that the operation is trying to convert an arbitrary
+billing date to a due date. (That's by far the most common case.) But that is
+almost always a fixed number of days ahead - 10 or 15 or 25 or 30 days from the
+billing date. We've already looked at and rejected that as an example, as
+month-end and leap year handling is a nightmare (it certainly is in
+Ada.Calendar.Arithmetic!).
+
+[B] The alternative is to have a contractual due date that doesn't change.
+That's much rarer in practice, and many of those adjust to avoid Sundays and
+holidays. Moreover, those have no relationship to the arbitrary billing date, so
+it doesn't make sense to even calculate one from the other.
+
+[C] Clearly, the problem I'm having is that the usage case is ill-defined and
+seems totally arbitrary. The objection to my suggestions seems to have mainly
+been that the usage case wasn't well-defined, and the same has to apply to the
+suggestions made by others. As it is, I feel I'm being held to a much higher
+standard, and that is what rankles the most.
+
+[D] Let's for a moment assume that you somehow have a contractual arrangement
+that is always due on the first. First of all, the use of a magic number as in
+the above example is always discouraged, and should be replaced by a constant
+(what if the law changes?). So that's unrealistic.
+
+[E] Moreover, the use of a day at all doesn't make sense in this "single date"
+context. Why would anyone store a value that never changes? That would be a
+massive waste of space (especially if this is for a large health insurer with
+very many customers). You'd use a type that just included the year and month. (A
+number of the bills I get are structured exactly that way; the bill itself isn't
+dated at all, it's just for a month.) Alternatively, you might use an existing
+time/date type. The one thing you would never do is define a custom type with a
+date component and then not use it for anything realistic.
+
+[F] There has to be a grace period in the dates in any realistic scenario; if
+you're figuring out the first due date of a new contract, the first payment
+isn't due until some time after signing. It would be madness to have a contract
+signed on July 31st require a payment due on August 1st.
+
+[G] Ergo, the Due_Dates array cannot contain arbitrary dates; they have to be
+limited in some way. A better scenario (IMHO) is to define the array to hold the
+Next_Due_Date, which is limited to hold only legitimate due dates. (In practice,
+one would want to enforce that with a predicate, but that's outside of this
+example.) Then the scenario would be to advance the due date because a full
+payment was successfully received.
+
+[H] But of course, if we restrict the values in the Next_Due_Date array, the
+previous version of the example works just as well. Just make sure that the
+restriction doesn't allow any day number over 28.
+
+[I] So I propose the following example:
+
+      Next_Due_Date : array (1 .. Max) of Date := ...;  -- See 3.3.2, 3.8
+          -- Customer payments are due on the 1st or 15th of the month.
+      ...
+      -- Customer Count (see 3.3.1) has paid in full this month; advance the due date:
+      Due_Dates(Count) :=
+            (Year  => (if @.Month = December then @.Year+1 else @.Year),
+             Month => (if @.Month = December
+                       then January else Month_Name'Succ(@.Month)),
+             Day   => @.Day);
+
+      AARM Discussion: We're taking advantage of the fact that the Day can only be 1 or 15
+      to simplify the calculation. If the Day could be late in the month, one would have to
+      adjust for short months and leap years.
+
+It would be better if the index was named Customer or something like that, but
+we don't have an example like that.
+
+I tend to agree with Erhard that the use of Count is annoying, because it
+doesn't really have much relation to the problem. But a for loop doesn't make
+much sense in this scenario, so I'm not proposing that.
+
+[J] This example is still unrealistic in that any sane programmer would create a
+function to do the above, at least to avoid having to retest the conditions
+multiple times. I'd probably write something like:
+      function Next_Month (The_Date : Date) return Date is
+      begin
+          return Result : Date := The_Date do
+             if Result.Month < December then
+                 Result.Month := Month_Name'Succ(Result.Month);
+             else
+                 Result.Month := January;
+                 Result.Year := @ + 1;
+             end if;
+             -- Adjust day for month-end here.
+         end return;
+      end Next_Month;
+
+which is both easier to understand and reusable.
+
+As such, an example not involving Date would be preferable.
+
+However, in the absence of a better suggestion, I'll use the example given in
+[I]. Let's see if you guys can keep me from sleeping the entire weekend...
+
+****************************************************************
+
+From: Brad Moore
+Sent: Sunday, August 14, 2016  1:14 PM
+
+> As such, an example not involving Date would be preferable.
+
+How about this?
+
+Locations : array (1 .. Max) of Painted_Point := ...;  -- See 3.3.2, 3.9.1, 3.9
+
+-- Shift all locations to the right
+for Pos in Locations'Range loop
+   Locations(Pos) := Painted_Point'(X => @.X + 1.0, Y => @.Y, Paint => @.Paint); end loop;
+
+This seems more realistic, where the Painted points are absolute locations, and
+one wants to update all the locations by a relative offset.
+
+It also involves a loop, which some mentioned they would prefer to see.
+
+> However, in the absence of a better suggestion, I'll use the example
+> given in [I]. Let's see if you guys can keep me from sleeping the
+> entire weekend...
+
+I thought it would be best to let you sleep in on Sunday, assuming you'd be
+having to get up earlier on Monday anyways.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, August 15, 2016  7:33 PM
+
+> It also involves a loop, which some mentioned they would prefer to
+> see.
+
+One minor problem with it, however, as written it would make more sense to just
+update the individual component. The example probably should involve multiple
+components. That's easy enough to do (see the next message).
+
+> > However, in the absence of a better suggestion, I'll use the example
+> > given in [I]. Let's see if you guys can keep me from sleeping the
+> > entire weekend...
+>
+> I thought it would be best to let you sleep in on Sunday, assuming
+> you'd be having to get up earlier on Monday anyways.
+
+Thanks, I think. :-)
+
+I know that it looks like I'm taking this example too seriously, but since these
+examples are likely to be the first exposure of Ada users (new and old) to this
+feature, I think it's important to get them right.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, August 15, 2016  7:35 PM
+
+...
+> Or using the other type in 3.8, how about
+>
+>   My_Complex_Array : array (1 .. Max) of Complex; -- 3.3.2, 3.8 begin
+>   -- Square first element
+>   My_Complex_Array (1) := (Re => @.Re**2 - @.Im**2,
+>                            Im => -2.0 * @.Re * @.Im);
+
+Some Jeff guy wanted the LHS to be more complex; it probably should use a
+variable (perhaps Count again). Otherwise looks fine.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, August 15, 2016  7:45 PM
+
+Thanks guys, now I have too many examples, and I don't have a clear winner in
+the bunch. So let me ask for preferences.
+
+First, let me remind you of the simple example (not in question here):
+
+   Board(1, 1) := @ + 1;  -- An abbreviation for Board(1, 1) := Board(1, 1) + 1;
+                          -- (Board is declared in 3.6.1).
+
+The question is what should follow this. We have three suggestions (in no
+particular order):
+
+(A)
+    My_Complex_Array : array (1 .. Max) of Complex; -- 3.3.2, 3.8
+    ...
+    -- Square the element in the Count (see 3.3.1) position:
+    My_Complex_Array (Count) := (Re => @.Re**2 - @.Im**2,
+                                 Im => -2.0 * @.Re * @.Im);
+       -- A target_name can be used multiple times and as a prefix if needed.
+(B)
+    Next_Due_Date : array (1 .. Max) of Date := ...;  -- See 3.3.2, 3.8
+        -- Customer payments are due on the 1st or 15th of the month.
+    ...
+    -- Customer Count (see 3.3.1) has paid in full this month; advance the due date:
+    Due_Dates(Count) :=
+         (Year  => (if @.Month = December then @.Year+1 else @.Year),
+          Month => (if @.Month = December
+                    then January else Month_Name'Succ(@.Month)),
+          Day   => @.Day);
+       -- A target_name can be used multiple times and as a prefix if needed.
+
+      AARM Discussion: We're taking advantage of the fact that the Day can only be 1 or 15
+      to simplify the calculation. If the Day could be late in the month, one would have to
+      adjust for short months and leap years.
+
+(C)
+    Locations : array (1 .. Max) of Painted_Point := ...;  -- See 3.3.2, 3.9.1, 3.9
+
+    -- Shift all locations down and to the right:
+    for Pos in Locations'Range loop
+       Locations(Pos) := Painted_Point'(X => @.X + 1.0, Y => @.Y + 1.0, Paint => @.Paint);
+           -- A target_name can be used multiple times and as a prefix if needed.
+    end loop;
+
+[Aside: Do we need the qualification here? If not, I'd rather drop it to
+simplify the example. Painted_Point is tagged.]
+
+Please indicate your preference and any comments. (In the next day or so in
+order that I can put this AI and the rest out for editorial review.)
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent