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

Differences between 1.4 and version 1.5
Log of other versions for file ai05s/ai05-0163-1.txt

--- ai05s/ai05-0163-1.txt	2009/12/06 02:35:02	1.4
+++ ai05s/ai05-0163-1.txt	2010/07/08 03:07:45	1.5
@@ -1,5 +1,8 @@
-!standard  2.8(7)                                  09-11-19  AI05-0163-1/01
+!standard  2.8(7)                                  10-07-07  AI05-0163-1/02
+!standard  2.8(16)
 !class binding interpretation 09-10-16
+!status Amendment 201Z 10-07-07
+!status ARG Approved  8-0-1  10-07-07
 !status work item 09-10-16
 !status received 09-06-28
 !priority Low
@@ -18,14 +21,14 @@
 
 !wording
 
-2.8(5-7.1/3) says:
+2.8(5-7.1/3) is modified (deleting text in 7/3 as marked, and adding a new bullet):
 
 5     Pragmas are only allowed at the following places in a program:
 
 6       * After a semicolon delimiter, but not within a formal_part or
           discriminant_part.
 
-7/3     * {AI05-0100-1} At any place where the syntax rules allow a construct
+7/3     * At any place where the syntax rules allow a construct
           defined by a syntactic category whose name ends with "
           declaration", "statement", "clause", or "alternative", or one of the
 	  syntactic categories variant or exception_handler; but not in place of
@@ -33,80 +36,34 @@
 	  that is required to have at least one such construct[, as in a
 	  sequence_of_statements].
 
-7.1/3   * {AI05-0100-1} At any place where a compilation_unit is allowed.
+        * {In place of a statement in a sequence_of_statements.}
 
-We modify 2.8(7.1/3) to remove the "[, as in a sequence_of_statements]" part.
+7.1/3   * At any place where a compilation_unit is allowed.
 
-7/3     * {AI05-0100-1} At any place where the syntax rules allow a construct
-          defined by a syntactic category whose name ends with "
-          declaration", "statement", "clause", or "alternative", or one of the
-	  syntactic categories variant or exception_handler; but not in place of
-	  such a construct if the construct is required, or is part of a list
-	  that is required to have at least one such construct.
-
-Add a new paragraph after that:
 
-        * In place of a statement in a sequence_of_statements.
+The following Language Design Principles and Implementation Advice are modified:
 
-The following Language Design Principles and Implementation Advice are removed:
-
                          Language Design Principles
 
-1.a/3     {AI05-0100-1} In general, if all pragmas are erased from a program,
+1.a/3     In general, if all pragmas are [erased from a program]
+          {treated as unrecognized pragmas},
           the program should remain both syntactically and semantically legal.
           There are a few exceptions to this general principle (for example,
           pragma Import can eliminate the need for a completion), but the
           principle remains, and is strictly true at the syntactic level.
           Certainly any implementation-defined pragmas should obey this
           principle both syntactically and semantically, so that if the
-          pragmas are simply ignored by some other implementation, the program
-          will remain legal.
+          pragmas are [simply ignored] {not recognized} by some other
+          implementation, the program will remain legal.
 
                             Implementation Advice
 
-16    Normally, implementation-defined pragmas should have no semantic effect
-for error-free programs; that is, if the implementation-defined pragmas are
-removed from a working program, the program should still be legal, and should
-still have the same semantics.
-
-16.a.1/2     Implementation Advice: Implementation-defined pragmas should have
-          no semantic effect for error-free programs.
-
-16.a      Ramification: Note that "semantics" is not the same as "effect;" as
-          explained in 1.1.3, the semantics defines a set of possible effects.
-
-16.b      Note that adding a pragma to a program might cause an error (either
-          at compile time or at run time). On the other hand, if the
-          language-specified semantics for a feature are in part
-          implementation defined, it makes sense to support pragmas that
-          control the feature, and that have real semantics; thus, this
-          paragraph is merely a recommendation.
-
-17    Normally, an implementation should not define pragmas that can make an
-illegal program legal, except as follows:
-
-18      * A pragma used to complete a declaration, such as a pragma Import;
-
-19      * A pragma used to configure the environment by adding, removing, or
-      replacing library_items.
-
-19.a.1/2     Implementation Advice: Implementation-defined pragmas should not
-          make an illegal program legal, unless they complete a declaration or
-          configure the library_items in an environment.
-
-19.a      Ramification: For example, it is OK to support Interface,
-          System_Name, Storage_Unit, and Memory_Size pragmas for upward
-          compatibility reasons, even though all of these pragmas can make an
-          illegal program legal. (The latter three can affect legality in a
-          rather subtle way: They affect the value of named numbers in System,
-          and can therefore affect the legality in cases where static
-          expressions are required.)
-
-19.b      On the other hand, adding implementation-defined pragmas to a legal
-          program can make it illegal. For example, a common kind of
-          implementation-defined pragma is one that promises some property
-          that allows more efficient code to be generated. If the promise is a
-          lie, it is best if the user gets an error message.
+16    Normally, implementation-defined pragmas should have no semantic
+      effect for error-free programs; that is, if the
+      implementation-defined pragmas {in a working program are replaced
+      with unrecognized pragmas} [are removed from a working program],
+      the program should still be legal, and should still have the same
+      semantics.
 
 !discussion
 
@@ -119,13 +76,8 @@
 
 Instead, one must insert "null;" either before or after the pragma.
 
-This AI allows the above without the "null;", because (1) we don't believe it
-aids readability in any way, and (2) the property of removing pragmas and
-retaining syntactic legality is of no practical value.  Removing pragmas,
-whether language-defined or implementation-defined, can already have a radical
-effect on the run-time behavior of the program, so retaining legality is
-pointless.  In fact, it is damaging, for the usual reasons that compile-time
-errors are preferable to run-time or totally-undetected errors.
+This AI allows the above without the "null;", because we don't believe it
+aids readability in any way.  
 
 Note that the wording "In place of a statement in a sequence_of_statements." (as
 opposed to "In place of a sequence_of_statements.") makes it clear that two or
@@ -170,29 +122,14 @@
 However that was considered to complicated.  For example, we're not sure how it
 would affect the conformance rules.
 
-Finally, all the verbiage that attempts to define what pragmas are "in good
-taste" is removed.  This AI makes such wording blatantly wrong -- removing the
-pragma Assert in the first example above makes the program syntactically
-illegal.  It makes no sense to talk about semantic legality if we don't even
-have syntactic legality.
-
-In any case, the "good taste" principles/advice are so full of exceptions that
-it is clear they don't really mean much.  We don't want to add more verbiage
-that has no practical effect -- most implementations are known to disobey the
-"good taste" principles/advice, and aren't about to change.  Such
-implementations can even claim to conform to the Advice, because it says
-"Normally,...", and an implementation can reasonably say, "Well, this particular
-pragma is not a normal one, and for good reason."
-
 Historical note:  In Ada 83, implementation-defined pragmas were forbidden to
 affect legality in either direction.  The intent in Ada 95 was to weaken this
 rule to only forbid pragmas that make an otherwise-illegal program legal, and to
-add the "Normally, ..." loophole.  We now remove all the "good taste"
-principles/advice, and leave matters of taste up to implementers.
-
-Note that this makes pragmas more similar to attributes -- implementations are
-allowed to have non-standard attributes, and removing them can certainly make
-programs illegal.
+add the "Normally, ..." loophole.  We have preserved that, but rather than
+requiring syntactic legality when the pragmas are removed, we simply require
+syntactic legality if the pragmas are treated as unrecognized pragmas.  That
+is the more important goal, namely that the program remains syntactically legal
+for implementations that don't recognize an implementation-defined pragma.
 
 Note that we retain the Requirement of a warning on unrecognized pragmas.
 
@@ -202,8 +139,43 @@
 difficult, and was rejected.  Some 100 BNF rules would need to be carefully
 inspected (all the ones endind in "declaration", "statement", etc), so this
 change was considered too error prone.
+
+!corrigendum 2.8(7)
+
+@drepl
+@xbullet<At any place where the syntax rules allow a construct defined by a
+syntactic category whose name ends with "@fa<declaration>", "@fa<statement>",
+"@fa<clause>", or "@fa<alternative>", or one of the syntactic categories
+@fa<variant> or @fa<exception_handler>;
+but not in place of such a construct.
+Also at any place where a @fa<compilation_unit> would be allowed.>
+@dby
+@xbullet<At any place where the syntax rules allow a construct defined by a
+syntactic category whose name ends with "@fa<declaration>", "@fa<item>",
+"@fa<statement>", "@fa<clause>", or "@fa<alternative>", or one of the
+syntactic categories @fa<variant> or @fa<exception_handler>;
+but not in place of such a construct if the construct is required, or is
+part of a list that is required to have at least one such construct.>
+
+@xbullet<In place of a @fa<statement> in a @fa<sequence_of_statements>.>
+
+@xbullet<At any place where a @fa<compilation_unit> is allowed.>
+
+!corrigendum 2.8(16)
+
+@drepl
+Normally, implementation-defined pragmas should have no semantic
+effect for error-free programs; that is, if the
+implementation-defined pragmas are removed from a working program,
+the program should still be legal, and should still have the same
+semantics.
+@dby
+Normally, implementation-defined pragmas should have no semantic
+effect for error-free programs; that is, if the
+implementation-defined pragmas in a working program are replaced
+with unrecognized pragmas, the program should still be legal, and
+should still have the same semantics.
 
-It is a pleasure to write up an AI that REDUCES the size of the RM!
 
 !ACATS Test
 

Questions? Ask the ACAA Technical Agent