CVS difference for ai12s/ai12-0212-1.txt

Differences between 1.16 and version 1.17
Log of other versions for file ai12s/ai12-0212-1.txt

--- ai12s/ai12-0212-1.txt	2018/10/19 01:24:46	1.16
+++ ai12s/ai12-0212-1.txt	2018/10/19 05:59:55	1.17
@@ -3615,3 +3615,82 @@
 
 ****************************************************************
 
+From: Randy Brukardt
+Sent: Thursday, October 18, 2018  8:36 PM
+
+Reading some of Brad's text, and started wondered about how qualified
+expressions work with container aggregates. It looks like one can write:
+
+     Attendance : constant My_Vector := My_Vector'["Tuck" => True, "Randy" => True, "Jeff" => False, ... ];
+
+to qualify a container aggregate. That's because the syntax of a qualified
+expression is:
+
+qualified_expression ::=
+   subtype_mark'(expression) | subtype_mark'aggregate
+
+Certainly, that's better than:
+
+     Attendance : constant My_Vector := My_Vector'(["Tuck" => True, "Randy" => True, "Jeff" => False, ... ]);
+
+but it's likely to be surprise to some (it was to me, until I looked up the
+exact syntax of qualified expression).
+
+Maybe we ought to have some examples like this.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, October 18, 2018  8:49 PM
+
+>> Here is an update to the container aggregate AI, switching over to
+>> using square brackets "[...]" for such aggregates.
+>
+> One thing I immediately noticed is missing here is an update to 2.2 to
+> add square brackets as an acceptable delimiter. That is, we need to
+> add square brackets to the lists in 2.2(9/5) and 2.1(15/5). Else
+> they're not acceptable syntax.
+
+Good point.
+
+> There's a second problem, and that is that our syntax form uses
+> brackets to denote optional items. We need to think of some way to
+> differentiate literal brackets from the use as a syntax form. (As it
+> stands, your syntax changes make aggregates optional. :-)
+
+I was presuming we could use a distinct font for the html/pdf versions (probably
+make the []'s used for optionality taller and thinner), and in text, something
+like '[' and ']' for uses of square bracket characters.
+
+> 1.1.4 has a hack for the vertical bar, that it stands for itself when
+> it appears immediately after a curly bracket. That sort of hack won't
+> work here, but we need *something*.
+
+See above for a suggestion.
+
+> Didn't notice anything else.
+
+OK, good to hear that.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, October 18, 2018  9:25 PM
+
+> I was presuming we could use a distinct font for the html/pdf versions
+> (probably make the []'s used for optionality taller and thinner), and
+> in text, something like '[' and ']' for uses of square bracket
+> characters.
+
+I'm pretty sure ISO will not be happy if we start using even more fonts. (Time
+for Comic Sans! :-) And doing it that way does mean a significant programming
+session for me, since some new capabilities would have to be added to the RM
+generator/'corrigendum processor/AI display generator to use a different font
+(or even bold vs. regular), in particular new markup. This isn't exactly the
+best time to engage in a new project of that sort. (I figure I have about 540
+hours of possible work time between the end of this meeting and the time we're
+supposed to deliver the RM -- and I don't know yet how much of that time will be
+funded. I probably already have work to use much of it in any case.)
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent