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

--- ai05s/ai05-0295-1.txt	2012/03/16 03:07:45	1.4
+++ ai05s/ai05-0295-1.txt	2012/04/21 04:39:19	1.5
@@ -950,6 +950,143 @@
 
 ****************************************************************
 
+From: Randy Brukardt
+Sent: Monday, January 16, 2012  9:20 PM
+
+Jeff Cousins opened his review of chapter 13 with the following:
+
+> Most of the detail looks fine to me, so trying to stand back a bit,
+> the structure of the opening few paragraphs looks a bit odd.
+> I think that rather than in the section specific to Operational and
+> Representation Items (13.1 0.1/3) saying that representation and
+> operational aspects may also be specified in some other way, it would
+> be better to say in the intro in section 13 1/1:
+> what representation and operational aspects are (preferably something
+> less vague than "other properties" for the latter); then that some may
+> be specified by Operational and Representation Items (see 13.1) and
+> some by Aspect Specifications (see 13.3.1).
+>
+> The term aspect specification would then be introduced before it is
+> used (e.g. by 13.1 9/3).
+
+This is probably a good idea. It seems related to the work Steve is doing, so I
+recommend that we  give it off to him to propose a replacement for the 13 1/1
+introduction (and possibly the 13.1 introduction as well, since we won't want to
+repeat the text again).
+
+As far as operational aspects being "other properties", please suggest something
+better that covers stream attributes, external tag, and properties like
+preelaborable initialization (along with properties yet to be invented). We
+tried back in 1999 and pretty much decided that "anything else" was the best
+description. The only real requirement is that they can be specified on a
+private view (unlike representation aspects).
+
+> In general through chapter 13 the emphasis should first be on what the
+> representation and operational aspects are, then say what the
+> mechanisms are for specifying them.
+
+We decided many years ago that we wouldn't renumber the clauses, because so many
+books, error messages, and the like depend on them. So we're pretty much stuck
+with the existing order of presentation, even if it is not ideal. One thing we
+may want to consider is moving 13.3.1 up to 13.1.1, since the idea of
+aspect_specification is more general than the specific attributes that make up
+the vast majority of 13.3.
+
+But I don't think we can do much beyond a bit of cosmetic patching to the bulk
+of 13.1. That means there is going to be a mixture of "representation aspects"
+and "representation item" rules here.
+
+To summarize, I'm suggesting:
+(1) That we ask Steve to update the introductions of 13 and 13.1 along with the
+    other work he is doing to generalize "representation items" to
+    "representation aspects".
+(2) We consider moving 13.3.1 (aspect_specifications) to 13.1.1, since it is the
+    most important way to specify aspects in Ada 2012. It should come as soon as
+    we can put it in without changing the text too much.
+
+[Aside: Jeff also wonders why some of the text uses "aspect of representation",
+and other text uses "representation aspect". The first term was introduced in
+Ada 95, and is mainly used in Ada 95-era text; the other comes from later work
+starting with Corrigendum 1 (where we introduced "operational aspect", since
+"aspect of operational" doesn't make any sense). There is an argument to make
+these all the same, but I'm not going to make it. I don't want to crush poor
+Steve. :-)]
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, January 17, 2012  8:33 AM
+
+> [Aside: Jeff also wonders why some of the text uses "aspect of
+> representation", and other text uses "representation aspect". The
+> first term was introduced in Ada 95, ...
+
+Actually, it predates Ada 9X -- I got it from the Ada 83 RM.
+13.1 says:
+
+  The effect of the elaboration of a representation clause is to define
+  the corresponding aspects of the representation.
+
+>...and is mainly used in Ada 95-era text; the other  comes from later
+>work starting with Corrigendum 1 (where we introduced  "operational
+>aspect", since "aspect of operational" doesn't make any sense).
+> There is an argument to make these all the same, but I'm not going to
+>make  it. I don't want to crush poor Steve. :-)]
+
+Yeah, if it ain't broke, don't fix it.
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Wednesday, January 18, 2012  7:25 AM
+
+I think it would make chapter 13 more coherent to standardise on "representation
+aspect", it doesn't affect many places.
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Wednesday, January 18, 2012  7:30 AM
+
+> As far as operational aspects being "other properties", please suggest
+> something better that covers stream attributes, external tag, and properties
+> like preelaborable initialization (along with properties yet to be invented).
+> We tried back in 1999 and pretty much decided that "anything else" was the
+> best description. The only real requirement is that they can be specified on a
+> private view (unlike representation aspects).
+
+Couldn't it say "such as " then give your list above?  And add the bit about
+private view as an AARM note?
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Tuesday, January 17, 2012  1:08 AM
+
+> An aspect_mark doesn't specify anything, it's just part of an
+> aspect_specification. If we want to talk about anything, it's the
+> unnamed "aspect_mark => aspect_definition" part of an
+> aspect_specification, since that is what really does the specifying.
+> Changing the syntax to give that a name (but what?) and then using that name here would work.
+
+Aspect_Association seems in line with the rest of the language (and I think
+we'll need that name for ASIS anyway)
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Wednesday, January 18, 2012  7:16 AM
+
+Thanks Jean-Pierre for that suggestion.  That would seem to fit, e.g. it's like
+X => Y for a pragma association.
+
+I think there might be several places in 13 which say aspect specification when
+they really should say aspect association (or whatever term we decide on) as
+they're talking about the setting of an individual aspect rather than the whole
+syntax construct  "with <comma_separated_list>".
+
+****************************************************************
+
 From: Steve Baird
 Sent: Thursday, January 26, 2012  6:39 PM