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

--- ai05s/ai05-0183-1.txt	2010/04/29 06:27:42	1.5
+++ ai05s/ai05-0183-1.txt	2010/05/20 03:23:30	1.6
@@ -771,3 +771,272 @@
 
 ****************************************************************
 
+From: Bob Duff
+Sent: Monday, May 10, 2010  2:25 PM
+
+This is my response to this homework item:
+
+AI05-0183-1: Work with Tucker on a list of declarations that don't allow
+aspect_specifications, and why not.
+
+which was assigned to me at the April 29 telephone meeting.
+I'm not sure about the "why not" part.
+
+There is a list of declarations that include aspect_spec in the !proposal, and
+again in the AARM.  The latter is missing generic_formal_parameter_declaration.
+It's also missing from the syntax rules.
+Seems like it should be included.
+I suggest putting the list only in the AARM, and put something like this in the
+proposal:
+
+  The aspect_specification is an optional element allowed by the syntax rules
+  for many kinds of declarations.
+
+Here's the list:
+
+    * object_declaration;
+    * full_type_declaration;
+    * subtype_declaration;
+    * component_declaration;
+    * subprogram_declaration;
+    * abstract_subprogram_declaration;
+    * null_procedure_declaration;
+    * package_declaration;
+    * private_type_declaration;
+    * private_extension_declaration;
+    * task_type_declaration;
+    * single_task_declaration;
+    * protected_type_declaration;
+    * single_protected_declaration;
+    * entry_declaration;
+    * generic_declaration;
+    * generic_formal_parameter_declaration.
+
+     [What about renaming declarations?]
+
+I did not carefully review the syntax rules in the AI to see if they in fact
+match the above list.
+
+Here's a list of all the kinds of declaration, with "*" marking the ones
+mentioned above, and NO marking the ones that currently do not allow an
+aspect_specification.
+
+basic_declaration
+  type_declaration
+    full_type_declaration*
+      ...
+      task_type_declaration*
+      protected_type_declaration*
+    incomplete_type_declaration  --  NO
+    private_type_declaration*
+    private_extension_declaration*
+  subtype_declaration*
+  object_declaration*
+    ...
+    single_task_declaration*
+    single_protected_declaration*
+  number_declaration  --  NO
+  subprogram_declaration*
+  abstract_subprogram_declaration*
+  null_procedure_declaration*
+  package_declaration*
+  renaming_declaration  --  NO
+  exception_declaration  --  NO
+  generic_declaration*
+  generic_instantiation  --  NO
+enumeration_literal_specification  --  NO
+discriminant_specification  --  NO
+component_declaration*
+loop_parameter_specification  --  NO
+parameter_specification  --  NO
+subprogram_body  --  NO
+entry_declaration*
+entry_index_specification  --  NO
+choice_parameter_specification  --  NO
+generic_formal_parameter_declaration*  (or NO -- not clear)
+extended_return_statement  --  NO
+
+I guess we should add renaming_declaration and exception_declaration.
+I guess generic_formal_parameter_declaration should be included.
+It seems a little odd to allow component_declaration, but not
+discriminant_specification.  Not sure about parameter_specification.
+
+Please discuss.  When that's done, we should add AARM text after the list of
+declarations that allow it, like:
+
+  The syntax rules do not allow aspect_specifications on the other kinds of
+  declarations, which are:
+
+    ... (list them)
+
+  Also, aspect_specifications are not allowed on bodies or accept statements,
+  even though these things are sort of like declarations, and in the case of
+  subprogram_bodies can actually be declarations. If you want an
+  aspect_specification on a subprogram, you have to give an explicit
+  declaration before the body.
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Monday, May 10, 2010  7:09 PM
+
+> I guess we should add renaming_declaration and exception_declaration.
+
+I agree those should be included.
+
+> I guess generic_formal_parameter_declaration should be included.
+
+Dunno.  Doesn't that get into matching complexities?
+
+> It seems a little odd to allow component_declaration, but not
+> discriminant_specification.  Not sure about parameter_specification.
+
+It does seem inconsistent to disallow them for discriminants.  Is there any
+significant argument for not allowing them on discriminants and parameter specs?
+I suppose it tends to interfere with readability, plus there's the issue of
+conformance for spec/body and multipart declarations.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, May 10, 2010  9:12 PM
+
+I am reluctant to allow specifying aspects on a renaming declaration.  That
+could really confuse the model and add a lot of complexity to handling renames,
+which are already pretty tricky.  I agree that exception declarations should
+allow aspect specifications.
+
+Randy suggested that by default, aspect specifications would not be permitted on
+generic_formal_parameter_decls, but that they could be permitted for particular
+aspects. We would have to define the matching rules for any aspects that we
+allow being specified on a generic formal.  But it seems like it could be useful
+at least in some cases.
+
+Allowing them on discriminants or parameters definitely adds complexity to
+conformance rules.  It doesn't seem so odd that discriminants are special, since
+they have other unique properties, such as being read-only, and being
+specifiable in a subtype indication, etc.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Tuesday, May 11, 2010  1:44 AM
+
+> I am reluctant to allow specifying aspects on a renaming declaration.
+> That could really confuse the model and add a lot of complexity to
+> handling renames, which are already pretty tricky.  I agree that
+> exception declarations should allow aspect specifications.
+
+I fully agree here. Aspects are a property of the entity, not of the view. We
+already have the problem that constraints on the subtype of a renaming are
+ignored, let's not make it worse.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, May 11, 2010  8:46 PM
+
+> I am reluctant to allow specifying aspects on a renaming declaration.
+> That could really confuse the model and add a lot of complexity to
+> handling renames, which are already pretty tricky.
+
+If we have no aspects that are specifiable on renames, we could still allow the
+syntax, just in case an implementation wants to do it for an impl-def aspect.
+Then whatever complexity there is belongs to the implementer.
+
+Renames can be dispatching ops.  So you can't put a precondition on one?  Hmm...
+
+>...I agree that exception declarations
+> should allow aspect specifications.
+>
+> Randy suggested that by default, aspect specifications would not be
+> permitted on generic_formal_parameter_decls, but that they could be
+> permitted for particular aspects.
+
+But that's true for everything.  That is, we define the syntax to allow
+aspect_specs on certain decls.  Then, for each aspect, we say "this is allowed
+on so-and-so decls".
+
+If there are no language-defined aspects that are allowed on
+generic_formal_parameter_decls, we can still allow the syntax.
+
+> We would have to define the matching rules for any aspects that we
+> allow being specified on a generic formal.
+
+If there are no language-defined ones, we can let implementers worry about that.
+
+>...But it seems like it could be useful at  least in some cases.
+>
+> Allowing them on discriminants or parameters definitely adds
+> complexity to conformance rules.  It doesn't seem so odd that
+> discriminants are special, since they have other unique properties,
+> such as being read-only, and being specifiable in a subtype
+> indication, etc.
+
+Again, all the complexity can be placed on the implementer, if all we do is
+allow the syntax.  On the other hand, the syntax gets pretty ugly in these
+cases.
+
+I don't feel strongly about any of this, except that I strongly believe we
+should have a list in the AARM of the decls (and bodies) that don't allow
+aspects syntactically, so we can be sure we did it deliberately.  I suggested
+wording in my previous e-mail.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, May 19, 2010  10:14 PM
+
+> This is my response to this homework item:
+>
+> AI05-0183-1: Work with Tucker on a list of declarations that don't
+> allow aspect_specifications, and why not.
+>
+> which was assigned to me at the April 29 telephone meeting.
+> I'm not sure about the "why not" part.
+
+I think you were supposed to explain why each basic declaration that doesn't
+allow aspect clauses doesn't allow aspect clauses. (I can't think of any way to
+say this that isn't redundant!) Maybe it would be better to say that there needs
+to be an explanation for each declaration on the list of declarations that don't
+allow aspect_clauses -- the idea being that the default is that they *are*
+allowed. This seems like useful information for the AARM.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, May 19, 2010  10:24 PM
+
+> > Randy suggested that by default, aspect specifications would not be
+> > permitted on generic_formal_parameter_decls, but that they could be
+> > permitted for particular aspects.
+>
+> But that's true for everything.  That is, we define the syntax to
+> allow aspect_specs on certain decls.  Then, for each aspect, we say
+> "this is allowed on so-and-so decls".
+
+Sadly, we don't do a good job of that for the existing aspects in Ada 95 and
+2005. However, the rule added by AI05-0106-1 (13.1(9.2/3)) should cover it, so
+we don't need any additional wording for this AI.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, May 14, 2010  8:08 AM
+
+I think AI05-0183-1 (Aspect Specifications) needs some verbiage about
+visibility.  In particluar, this (from Yannick's recent ada-comment@ e-mail):
+
+   type Part (Max_Players : Positive) is record
+      ...
+      Num_Players : Positive;  --  Number of players
+      Pos         : Positions (1 .. Max_Players);  --  Position of each player
+   end record
+    with Predicate => Num_Players in 1 .. Max_Players;
+
+should be legal.  So should this:
+
+    with Predicate => Part.Num_Players in 1 .. Part.Max_Players;
+
+****************************************************************
+