CVS difference for 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