CVS difference for ai05s/ai05-0153-3.txt

--- ai05s/ai05-0153-3.txt	2011/01/27 06:06:16	1.4
+++ ai05s/ai05-0153-3.txt	2011/02/08 08:21:06	1.5
@@ -1139,7 +1139,8 @@
 From: Robert Dewar
 Sent: Monday, January 24, 2011  9:00 AM
 
-But don't worry too much, in the forseeable future only GNAT will implement Ada 2012 and there you will have one predicate that does both :-)
+But don't worry too much, in the forseeable future only GNAT will implement Ada
+2012 and there you will have one predicate that does both :-)
 
 > Because that will cause Randy and others to "snap", and we won't have
 > this extremely useful feature at all.
@@ -1219,85 +1220,6 @@
 
 ****************************************************************
 
-From: Bob Duff
-Sent: Monday, January 24, 2011  9:52 AM
-
-> P.S. should we have a restriction
->
-> No_Implementation_Aspects
-
-Yes, good idea.
-
-****************************************************************
-
-From: Bob Duff
-Sent: Monday, January 24, 2011  10:02 AM
-
-By the way, obviously some folks would like to forbid Dynamic_Predicate, so there should be a restriction for that.  Instead of doing it piecemeal, we should do like we did for No_Dependence, and have a general feature for forbidding any aspect.  Somethin
g like:
-
-    pragma Restrictions (No_Aspect => Dynamic_Predicate);
-
-We could have an enum type somewhere that lists all the aspect names.  Or we
-could just allow an "aspect_identifier" there, without involving visibility --
-like pragma arguments.  For aspects that are also attributes or pragmas, the
-restriction should forbid both forms.
-
-I've got no problem with self-imposed or project-imposed restrictions!  If,
-someday, some customer requests No_Evil_Predicates, I expect AdaCore would
-implement it (if we can come up with a coherent definition of "evil").
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Monday, January 24, 2011  10:19 AM
-
-Or perhaps something like:
-
-   pragma Restrictions(No_Aspect_Specification => Dynamic_Predicate);
-
-to be analogous to "No_Dependence => ...".
-
-****************************************************************
-
-From: Bob Duff
-Sent: Monday, January 24, 2011  10:38 AM
-
-Yes, that's better.  For those aspects that are also attributes, you probably
-want to restrict the specification, but not the query.
-
-****************************************************************
-
-From: Robert Dewar
-Sent: Tuesday, January 25, 2011   6:14 AM
-
-> Or perhaps something like:
->
->     pragma Restrictions(No_Aspect_Specification =>
-> Dynamic_Predicate);
->
-> to be analogous to "No_Dependence =>  ...".
-
-Can't we just have
-
-   No_Aspect => name
-
-I see no advantage to reader or writer in adding the Specification part here,
-especially if it also bans a corresponding pragma or attribute.
-
-****************************************************************
-
-From: Robert Dewar
-Sent: Tuesday, January 25, 2011   6:15 AM
-
-> Yes, that's better.  For those aspects that are also attributes, you
-> probably want to restrict the specification, but not the query.
->
->> to be analogous to "No_Dependence =>  ...".
-
-OK, I see, grumble, I guess the long name will have to do
-
-****************************************************************
-
 From: Randy Brukardt
 Sent: Monday, January 24, 2011  9:29 PM
 
@@ -1377,7 +1299,10 @@
 expression at all, but just a list of choices. It can't be static by itself. You
 probably want to borrow the 4.9(13) wording for memberships:
 
-...and whose membership_choice_list consists only of membership_choices each of which is either a static choice_expression, a static range, or a subtype_mark that denotes range is a static range or whose subtype_mark denotes a static [(scalar or string)] 
subtype;
+...and whose membership_choice_list consists only of membership_choices each of
+which is either a static choice_expression, a static range, or a subtype_mark
+that denotes range is a static range or whose subtype_mark denotes a static
+[(scalar or string)] subtype;
 
 Probably there is some way to simplify this, but I'll leave that as an exercise
 for the author.
@@ -1731,3 +1656,133 @@
 
 ****************************************************************
 
+[The following mail should go into a new AI, still TBD:]
+
+From: Bob Duff
+Sent: Monday, January 24, 2011  9:52 AM
+
+> P.S. should we have a restriction
+>
+> No_Implementation_Aspects
+
+Yes, good idea.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, January 24, 2011  10:02 AM
+
+By the way, obviously some folks would like to forbid Dynamic_Predicate, so
+there should be a restriction for that.  Instead of doing it piecemeal, we
+should do like we did for No_Dependence, and have a general feature for
+forbidding any aspect.  Something like:
+
+    pragma Restrictions (No_Aspect => Dynamic_Predicate);
+
+We could have an enum type somewhere that lists all the aspect names.  Or we
+could just allow an "aspect_identifier" there, without involving visibility --
+like pragma arguments.  For aspects that are also attributes or pragmas, the
+restriction should forbid both forms.
+
+I've got no problem with self-imposed or project-imposed restrictions!  If,
+someday, some customer requests No_Evil_Predicates, I expect AdaCore would
+implement it (if we can come up with a coherent definition of "evil").
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, January 24, 2011  10:19 AM
+
+Or perhaps something like:
+
+   pragma Restrictions(No_Aspect_Specification => Dynamic_Predicate);
+
+to be analogous to "No_Dependence => ...".
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, January 24, 2011  10:38 AM
+
+Yes, that's better.  For those aspects that are also attributes, you probably
+want to restrict the specification, but not the query.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, January 25, 2011   6:14 AM
+
+> Or perhaps something like:
+>
+>     pragma Restrictions(No_Aspect_Specification =>
+> Dynamic_Predicate);
+>
+> to be analogous to "No_Dependence =>  ...".
+
+Can't we just have
+
+   No_Aspect => name
+
+I see no advantage to reader or writer in adding the Specification part here,
+especially if it also bans a corresponding pragma or attribute.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, January 25, 2011   6:15 AM
+
+> Yes, that's better.  For those aspects that are also attributes, you
+> probably want to restrict the specification, but not the query.
+>
+>> to be analogous to "No_Dependence =>  ...".
+
+OK, I see, grumble, I guess the long name will have to do
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, July 26, 2010   7:46 PM
+
+Implementations are allowed to add grandchildren to Ada etc. And GNAT
+takes advantage of this, e.g. to add the encoding packages to earlier
+versions of Ada.
+
+But this creates portability problems, we should really have a
+restriction to prevent this, in the style of No_Implementation_Pragmas.
+
+How about No_Implementation_Units
+
+?
+
+I am not really suggesting a new AI at this stage, just some guidance
+on whether this is a good idea so that implementations can adopt it
+(and then we can put it into Ada 2019 :-))
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, July 26, 2010   8:14 PM
+
+This sounds like a very good idea.
+Users are often confused about what
+packages are "standard" Ada and what
+are not.
+
+Does this also cover System.* and Interfaces.*?
+One rule might be to disallow any package that starts with "Ada", "System",
+or "Interfaces" that is not in the reference manual.  These are the ones
+that confuse users.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, July 26, 2010   8:33 PM
+
+Right, that's what I had in mind.
+
+And the idea would be in particular to forbid use of RM packages in an
+inappropriately earlier version of Ada (e.g. using the string encoding packages
+in Ada 2005 mode). Of course I know that can't be part of the standard, but
+that would be the encouraged usage (and is what GNAT intends to do).
+
+****************************************************************