AI22-0045-1
!standard 2.8(6/5) 23-06-12 AI22-0045-1/06
!standard 2.8(7/3)
!standard 2.8(7.1/3)
!standard 2.8(7.2/3)
!standard 2.8(12)
!standard 2.8(20)
!standard 4.5.9(7/5)
!standard 10.2.1(23)
!standard 11.4.2(4/2)
!standard 13.1(4/1)
!standard H.3.2(4)
!standard J.15(1/3)
!class binding interpretation 22-06-16
!status Amendment 1-2022 22-09-09
!status WG9 Approved 23-10-12
!status ARG Approved 7-0-1 23-06-12
!status work item 23-06-05
!status ARG Approved 10-0-0 22-09-09
!status work item 22-06-16
!status received 22-03-22
!submitter Stephen Baird
!priority Medium
!difficulty Medium
!qualifier Clarification
!subject Issues with pragma placement
Five kinds of pragmas are identified, each with their own placement restrictions. Pragma Assert and pragma Inspection_Point are executable pragmas. The other kinds are configuration, context, aspect-related, and control.
Pragma placement is currently defined in 2.8 (5-8) as follows:
Pragmas are only allowed at the following places in a program:
6/5 After a semicolon delimiter, but not within a formal_part, discriminant_part, or declare_expression.
7/3 At any place where the syntax rules allow a construct defined by a syntactic category whose name ends with “declaration”, “item”, “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.
7.1/3 In place of a statement in a sequence_of_statements.
7.2/3 At any place where a compilation_unit is allowed.
8 Additional syntax rules and placement restrictions exist for specific pragmas.
These rules overlap with one another, and do not make sense for certain kinds of pragmas. Pragmas that are "lexical" in nature, such as turning on and off compiler modes of various sorts, such as listing or optimization, can be accommodated almost anywhere. On the other hand, pragmas that have some executable semantics only make sense in places where execution is normally occurring, such as in a sequence of statements or declarative_items. Should we distinguish such kinds of pragmas here, or rely on additional rules scattered throughout the manual?
Other more specific issues:
(1) One would expect that a pragma Assert is a master. We would not want function results from the evaluation of an Assert expression hanging around. AI22-0013-2 attempted to clarify this by modifying 2.8(12) to say:
Any pragma that appears at the place of an executable construct is executed, and is treated for the purposes of other rules of the language as being of the same sort of executable construct. Unless otherwise specified for a particular pragma, this execution consists of the evaluation of each evaluable pragma argument in an arbitrary order.
In the case of a pragma replacing a statement as allowed by 2.8(7.1/2), it is clear that the pragma is treated as a statement. Unfortunately, a statement is not a master construct (that requires a simple_statement), so it appears that a pragma given at the place of a statement is not a master (or at a minimum it is not clear). Since the point of AI22-0013-2 was to clarify questions like this, further clarification is needed.
(2) However, most of the rules of 2.8 are not as clear about the construct that the pragma is at the place of. In particular, 2.8(6/5) ["after a semicolon delimiter"] does not talk about constructs at all. Moreover, multiple placement rules could apply: for example, a pragma following a statement in a sequence_of_statements is allowed by both 2.8(7.1/3) (which is clear about the construct "at the place of") and 2.8(6/5) (which is not). How do we decide which rule is the reason the pragma is allowed at a particular place?
(3) Some of the places that pragmas are allowed are not at the place of any executable construct. What happens for executable pragmas in such locations? When are they executed? Are they a master? And so on.
For example, 2.8(7/3) allows a pragma at the place of an _alternative; this allows a pragma at the head of a case statement:
case P is
pragma Assert (...) -- (1)
when 1 => ... -- (2)
pragma Assert (...) -- (3)
when others => ...
end case;
It is clear that (3) is at the place of a statement, and thus is executed after the statements at (2) (and only if the statements at (2) are executed). But (1) is not at the place of a statement (it is in place of a case_statement_alternative), and this part of a case statement is never executed.
(4) AI12-0236-1 modified 2.8(6/5) to disallow pragmas in declare_expressions. However, a declare_expression contains a list of declare_items. Therefore, 2.8(7/3) allows pragmas in the list of declare_items, specifically the place that 2.8(6/5) is trying to disallow. Something is wrong here.
In general, we propose to provide more guidelines about pragmas in 2.8.
For (1), the hypothesis that a pragma Assert is not a master, is incorrect. In fact, all statements are masters, according to RM 7.6.1(3/5), and if a pragma is in place of a statement, it would become a master.
For (2), we propose to identify multiple kinds of pragmas, and limit which placement rules apply to each kind of pragma.
For (3), we propose to introduce the notion of an executable pragma as one of the kinds of pragmas (as mentioned in (2) above), and then indicate that the Assert pragma is an executable pragma as is an Inspection_Point pragma.
For (4), we permit executable pragmas within declare expressions (pragma Assert and pragma Inspection_Point are the only language-defined executable pragmas).
Modify[a] 2.8(5-8) as follows:
{There are five kinds of pragmas: configuration pragmas (and pragmas usable as configuration pragmas), context pragmas, aspect-related pragmas, executable pragmas, and control pragmas, and each has its own placement restrictions:
Additional syntax rules and placement restrictions exist for specific pragmas.
AARM Discussion: See J.15 for additional placement rules for aspect-related pragmas.
Modify 2.8(12): (Note: This includes the approved modification of AI22-0013-2, which is not yet in any published draft).
An[y] {executable or aspect-related} pragma that appears [at the]{in} place of an executable construct is executed{, and is treated for the purposes of other rules of the language as being a simple_statement, basic_declarative_item, or declare_item according to where it appears}. Unless otherwise specified for a particular pragma, this execution consists of the evaluation of each evaluable pragma argument in an arbitrary order.
Modify 2.8(20):
The forms of {the} List, Page, and Optimize {control} pragmas are as follows:
Modify 4.5.9(7/5):
The following are not allowed within a declare_expression: a declaration containing the reserved word aliased; the attribute_designator Access or Unchecked_Access; [or ]an anonymous access type{; or a pragma other than an executable pragma (see 2.8)}.
Modify 10.2.1(23):
A pragma Elaborate or Elaborate_All {is a context pragma (see 2.8)[Redundant:, and} is only allowed within a context_clause{]}.
Modify 11.4.2(4/2):
A pragma Assert {is an executable pragma (see 2.8)[Redundant:, and} is allowed at the place where a [declarative_item]{basic_declaration, declare_item,} or [a] statement is allowed{]}.
Modify 13.1(4/1):
A representation pragma {is an aspect-related pragma (see 2.8)[Redundant:, and} is allowed only at places where an aspect_clause or compilation_unit is allowed{]}.
Modify H.3.2(4):
A pragma Inspection_Point{is an executable pragma (see 2.8)[Redundant:, and} is allowed wherever a [declarative_item]{basic_declaration, declare_item,} or statement is allowed{]}. Each object_name shall statically denote the declaration of an object.
Modify J.15(1/3):
Pragmas can be used as an alternative to aspect_specifications to specify certain aspects. {Such pragmas are aspect-related pragmas (see 2.8).}
In part to respond to the confusion associated with issue part (1), we now limit "executable" pragmas to being in place of a simple_statement, a basic_declaration, or a declare_item. The syntactic construct "statement" actually includes the label, if any. But we want to allow a label on a pragma, so we specify a simple_statement. We also want temporaries associated with the pragma, rather than the expression, for an executable pragma, which is determined by whether the expression is immediately enclosed in a simple_statement as opposed to a compound_statement. As mentioned the only language-defined executable pragmas are Assert and Inspection_Point, and these will be treated as the kind of construct they replace, so you could, for example, put a statement label on an Inspection_Point.
For (2), we define five kinds of pragmas. The term "control" pragma is not ideal, but since it included the List pragma, and the Optimize pragma, it seemed reasonable. "Lexical" pragma seemed like a misnomer for an Optimize pragma.
A more general fix would be to replace 2.8(6/5, 7/3, 7.1/3, and 7.2/3) with actual syntax placement rules. This idea was rejected in AI05-0163-1 because it was "requiring the inspection of more than 100 BNF rules". Tucker Taft suggests that modification of 5 rules would allow all of the places people really care about.
simple_statement ::= ... | pragma
library_unit_declaration ::= ... | pragma
context_item ::= ... | pragma
aspect_clause ::= ... | pragma
generic_formal_part ::= generic
{generic_formal_parameter_declaration | use_clause | pragma}
The use of aspect_clause cleverly allows pragmas in virtually all sorts of declarations.
However, these rules would not allow pragmas in a few places the current rules allow, including between the is and first when of a case statement, and between the select and an alternative for select_statements. These positions are only likely to be useful for control pragmas like pragma Page and pragma List(Off), and even then it seems a bit bizarre to split a statement in a listing. However, now that we have multiple kinds of pragmas, using syntax rules gets more complicated, so we have decided to stick with English-based syntax rules.
For (3), we now limit executable pragmas to appearing in place of a simple_statement, a basic_declaration, or a declare_item, so that eliminates the danger of having masters appearing in places that are not normally elaborated or executed.
For pragma Assert, there already is a rule (11.4.2(4/2)) which prevents pragma placements like the first one in the third Issue. There are not any other language-defined pragmas that need to execute, though Inspection_Point is almost like an executable construct, since it represents a "break" in the flow of code to allow inspection of an intermediate state. In any case, it is unusual to have two closely related rules in very different parts of the RM, especially as it would be easy for new pragmas to forget the required placement rule. So we have moved the special placement rules for pragma Assert and Inspection_Point to 2.8, but we leave behind updated and redundant versions of the original placement rules.
For (4), we choose to allow executable pragmas in declare_expressions, but do not allow other kinds of pragmas.
The intent of all of the rules surrounding declare expressions was to keep the implementation extremely simple, and to allow an entire expression to be the smallest unit of change in a compiler. Changing properties in the middle of an expression could be problematic for some implementations, and it did not seem important enough of a capability to require implementations to change their basic design.
For example, how important is it to allow the specification of pragma Suppress and (especially, since it cannot be ignored) pragma Unsuppress in the middle of an expression? Consider this:
procedure P is
pragma Suppress (All_Checks);
begin
A := B + (declare
pragma Unsuppress
(All_Checks);
begin
C * D);
end P;
If the implementation normally suppresses overflow checks in the scope of a pragma Suppress, the pragma Unsuppress would have to turn the checks back on - an overflow check is required at the multiply in the above. However, if the implementation uses global flags to control overflow and expressions are evaluated at one time, it might require substantial efforts to get this example to work. (Similar issues apply to other pragmas that affect global settings, such as Optimize.)
These sorts of expressions were designed to be used in assertions like predicates and preconditions. Those are not even evaluated where they are declared, so one would have to be able to defer the effect of a pragma until some later point. For some pragmas, that would be a new capability.
For all of these reasons, we only allow executable pragmas (whose effects are well-defined) in declare_expressions. We considered allowing implementations to support other pragmas, but that would add another potential portability gotcha for little actual capability, so we do not allow other pragmas at all.
(See Issue and Discussion.)
@drepl
@fa{Pragma}s are only allowed at the following places in a program:
@dby
There are five kinds of pragmas: configuration pragmas (and pragmas usable as configuration pragmas), context pragmas, aspect-related pragmas, executable pragmas, and control pragmas, and each has its own placement restrictions:
@drepl
@xbullet{After a semicolon delimiter, but not within a @fa{formal_part}, @fa{discriminant_part}, or @fa{declare_expression}.}
@dby
@xbullet{A @i{configuration} pragma is allowed at the beginning of a @fa{compilation}, preceded only by other pragmas. In addition, certain pragmas are @i{usable as configuration pragmas}, and can also control configuration more locally; as such these pragmas can appear immediately within a @fa{declarative_part} or a @fa{package_specification} at the place of a @fa{basic_declaration}, as defined for specific pragmas.}
@drepl
@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.}
@dby
@xbullet{A @i{context} pragma is allowed at the place of a @fa{use_clause} in a @fa{context_clause}.}
@drepl
@xbullet{In place of a @fa{statement} in a @fa{sequence_of_statements}.}
@dby
@xbullet{An @i{aspect-related} pragma is allowed in place of an @fa{aspect_clause}, or immediately following (except for other pragmas) a compilation unit.}
@drepl
At any place where a @fa{compilation_unit} is allowed.
@dby
@xbullet{An @i{executable} pragma is allowed in place of a @fa{simple_statement}, or in place of a @fa{basic_declaration} or a @fa{declare_item}.}
@xbullet{Unless specified otherwise, a @i{control} pragma is allowed at the following places in a program:}
@xinbull{After a semicolon delimiter, but not within a @fa{formal_part} or @fa{discriminant_part}.}
@xinbull{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.}
@drepl
Any @fa{pragma} that appears at the place of an executable construct is executed. Unless otherwise specified for a particular pragma, this execution consists of the evaluation of each evaluable pragma argument in an arbitrary order.
@dby
An executable or aspect-related @fa{pragma} that appears in place of an executable construct is executed, and is treated for the purposes of other rules of the language as being a @fa{simple_statement}, @fa{basic_declarative_item}, or @fa{declare_item} according to where it appears. Unless otherwise specified for a particular pragma, this execution consists of the evaluation of each evaluable pragma argument in an arbitrary order.
@drepl
The forms of List, Page, and Optimize @fa{pragma}s are as follows:
@dby
The forms of the List, Page, and Optimize control @fa{pragma}s are as follows:
@drepl
The following are not allowed within a @fa{declare_expression}: a declaration containing the reserved word @b{aliased}; the @fa{attribute_designator} Access or Unchecked_Access; or an anonymous access type.
@dby
The following are not allowed within a @fa{declare_expression}: a declaration containing the reserved word @b{aliased}; the @fa{attribute_designator} Access or Unchecked_Access; an anonymous access type; or a pragma other than an executable pragma (see @ref{2.8}).
@drepl
A @fa{pragma} Elaborate or Elaborate_All is only allowed within a @fa{context_clause}.
@dby
A @fa{pragma} Elaborate or Elaborate_All is a context pragma (see @ref{2.8}), and is only allowed within a @fa{context_clause}.
@drepl
A @fa{pragma} Assert is allowed at the place where a @fa{declarative_item} or a @fa{statement} is allowed.
@dby
A @fa{pragma} Assert is an executable pragma (see @ref{2.8}), and is allowed at the place where a @fa{basic_declaration}, @fa{declare_item}, or @fa{statement} is allowed.
@drepl
A representation pragma is allowed only at places where an @fa{aspect_clause} or @fa{compilation_unit} is allowed.
@dby
A representation pragma is an aspect-related pragma (see @ref{2.8}), and is allowed only at places where an @fa{aspect_clause} or @fa{compilation_unit} is allowed.
@drepl
A pragma Inspection_Point is allowed wherever a @fa{declarative_item} or @fa{statement} is allowed. Each @i{object_}name shall statically denote the declaration of an object.
@dby
A pragma Inspection_Point is an executable pragma (see @ref{2.8}), and is allowed wherever a @fa{basic_declaration}, @fa{declare_item}, or @fa{statement} is allowed. Each @i{object_}@fa{name} shall statically denote the declaration of an object.
@drepl
Pragmas can be used as an alternative to @fa{aspect_specification}s to specify certain aspects.
@dby
Pragmas can be used as an alternative to @fa{aspect_specification}s to specify certain aspects. Such pragmas are aspect-related pragmas (see @ref{2.8}).
One could add some B-Tests that the various kinds of pragmas aren’t allowed in places that are allowed for control pragmas, but most of those restrictions already exist for specific pragmas (and should be tested for them), so additional more general tests would not add much.
Similarly, C-tests that executable pragmas are executed at the proper place and acts as a master ought to exist for the specific pragmas, so again more general tests would also not add much.
This AI is partially in response to ARG Github Issues #7 (https://github.com/Ada-Rapporteur-Group/User-Community-Input/issues/7) and #9 (https://github.com/Ada-Rapporteur-Group/User-Community-Input/issues/9).
From:: Niklas Holsti
Sent: Sunday, June 04, 2023 12:58 PM (WG 9 list)
After reviewing these AIs I have some comments on four of them ...
[Editor’s note: This AI just contains the part relevant to this AI, same for the replies below.]
- The "issue" text says that "Unfortunately, a statement is not a master construct (that requires a simple_statement)". However, RM 7.6.1(3/5) defines statements as master constructs, as I read it (in Draft 35; perhaps it has been changed since?).
- The proposed replacement for 2.8(5-8) says that an executable pragma is allowed in place of a "simple_statement". But it would be simpler to say "statement", and it would have the same syntactic effect because a "simple_statement" can appear in place of any "statement" and cannot appear anywhere else (by the syntax rules, but perhaps I am forgetting some prose legality rule). Indeed, the "redundant" text added to
11.4.2(4/2) and H.3.2(4) uses "statement", not "simple_statement". If accepted, this tweak should be done also to the proposed modification of 2.8(12).
- The proposed replacement for 2.8(5-8) says that a control pragma is allowed any place where "any other kind of pragma" is permitted. To me this feels a little ambiguous, because I could read "any other kind"
either as "some other kind" (the union of the places where other kinds of pragmas can appear) or as "all other kinds" (the intersection of places where other kinds of pragmas can appear). I assume the first reading (some other kind) is meant.
- In the same rule for control pragmas, if "any other kind" is to be read as "some other kind", it seems redundant to include syntactic categories with names ending in "statement" in the second "in addition"
bullet, because executable pragmas can appear any place where a statement can appear. But perhaps the intent is to emphasize that control pragmas cannot appear "in place of" statements (or the other listed syntactic constructs)?
- The proposed modification of 4.5.9(7/5) says that a declare_expression can contain an executable pragma, but cannot contain other kinds of pragmas. This seems to contradict the modified 2.8(5-8) which says that control pragmas are allowed in any place where any other kind of pragma is permitted, so control pragmas would be allowed in declare_expressions (again, assuming that "any other kind" should be read as "some other kind").
- The "redundant" part of the proposed modification of 13.1(4/1) says that an aspect-related pragma is allowed only at places where an aspect_clause or compilation_unit is allowed. This is not exactly the same as the proposed (normative) rule in the new 2.8(5-8), which says that "aspect-related pragmas are allowed in place of an aspect_clause"
(so far, so good) "or immediately following (except for other pragmas) a compilation unit" (which seems to disallow putting an aspect-related pragma in place of a first or only compilation unit, as allowed by the modification of 13.1(4/1)).
- Perhaps the new 2.8(5-8), or its annotations, should reference J.15, because J.15 gives additional rules on pragma placement and further classification of pragmas.
From: Tucker Taft
Sent: Monday, June 05, 2023 11:53 AM (WG 9 list)
>- The "issue" text says that "Unfortunately, a statement is not a master
>construct (that requires a simple_statement)". However, RM 7.6.1(3/5)
>defines statements as master constructs, as I read it (in Draft 35;
>perhaps it has been changed since?).
Interesting. When working on the AI somehow we convinced ourselves that only a simple_statement was a master construct, but in fact, you are correct. Every statement is considered a master construct. Simple_statements do appear in the rules, but only when deciding whether an outermost expression is a master construct. There is no need for an expression to be a master when immediately enclosed by a simple_statement, but there is a need for it to be a master when immediately enclosed by a compound statement, such as a condition of an if_statement, because the finalization of temporaries created by such an expression should be finalized before reaching the end of the enclosing compound statement.
>- The proposed replacement for 2.8(5-8) says that an executable pragma
>is allowed in place of a "simple_statement". But it would be simpler to
>say "statement", and it would have the same syntactic effect because a
>"simple_statement" can appear in place of any "statement" and cannot
>appear anywhere else (by the syntax rules, but perhaps I am forgetting
>some prose legality rule). Indeed, the "redundant" text added to
>11.4.2(4/2) and H.3.2(4) uses "statement", not "simple_statement". If
>accepted, this tweak should be done also to the proposed modification of
>2.8(12).
I think this was part of our overall confusion about simple_statement vs. statement, and I would agree it is more straightforward to talk in terms of statements here as well.
>- The proposed replacement for 2.8(5-8) says that a control pragma is
>allowed any place where "any other kind of pragma" is permitted. To me
>this feels a little ambiguous, because I could read "any other kind"
>either as "some other kind" (the union of the places where other kinds
>of pragmas can appear) or as "all other kinds" (the intersection of
>places where other kinds of pragmas can appear). I assume the first
>reading (some other kind) is meant.
I am not sure I see any ambiguity here, and I am not sure shifting to "some other kind" would be easier to understand. "Any" seems clearly different (to me!) from "all" or "every", while "some" seems to be potentially more restrictive than "any".
>- In the same rule for control pragmas, if "any other kind" is to be
>read as "some other kind", it seems redundant to include syntactic
>categories with names ending in "statement" in the second "in addition"
>bullet, because executable pragmas can appear any place where a
>statement can appear. But perhaps the intent is to emphasize that
>control pragmas cannot appear "in place of" statements (or the other
l>isted syntactic constructs)?
"In place of" is different from "at the place of". We are not allowing control pragmas to occur in place of a statement that is not part of a sequence_of_statements.
>- The proposed modification of 4.5.9(7/5) says that a declare_expression
>can contain an executable pragma, but cannot contain other kinds of
>pragmas. This seems to contradict the modified 2.8(5-8) which says that
>control pragmas are allowed in any place where any other kind of pragma
>is permitted, so control pragmas would be allowed in declare_expressions
>(again, assuming that "any other kind" should be read as "some other
>kind").
We may want to add in front of the description of control pragma "unless otherwise specified". I am also thinking at this point that we could simplify the description of control pragmas to eliminate any mention of "any other kind of pragma," and say simply:
* Unless specified otherwise, a control pragma is allowed at the following places in a program:
>- The "redundant" part of the proposed modification of 13.1(4/1) says
>that an aspect-related pragma is allowed only at places where an
>aspect_clause or compilation_unit is allowed. This is not exactly the
>same as the proposed (normative) rule in the new 2.8(5-8), which says
>that "aspect-related pragmas are allowed in place of an aspect_clause"
>(so far, so good) "or immediately following (except for other pragmas) a
>compilation unit" (which seems to disallow putting an aspect-related
>pragma in place of a first or only compilation unit, as allowed by the
>modification of 13.1(4/1)).
Agreed, those are not consistent. It makes little sense to have an aspect-related pragma in front of the first compilation_unit, so we should probably add (other than the first) in parentheses.
>- Perhaps the new 2.8(5-8), or its annotations, should reference J.15,
>because J.15 gives additional rules on pragma placement and further
>classification of pragmas.
We don't generally reference information in the Obsolescent Annex from the main part of the manual. We already indicate that individual pragmas can impose their own placement restrictions. The overall goal of moving features to the Obsolescent Annex is that a normal user does not need to be aware of anything in that Annex. So we don't want to imply that a normal user should refer to annex J to understand anything about the rest of the language.
From: Niklas Holsti
Sent: Monday, June 05, 2023 3:06 PM (WG 9 List)
> I am not sure I see any ambiguity here, and I am not sure shifting to
> "some other kind" would be easier to understand. "Any" seems clearly
> different (to me!) from "all" or "every", while "some" seems to be
> potentially more restrictive than "any".
I will of course defer to native English speakers. However, it seems to me that if one has a logical predicate P(X) then saying "P(X) is true for any X" usually means "P(X) is true for all X", and does not mean "P(X) is true for some X".
Also, Ada quantified expressions use "some", not "any" :-)
[...]
> I am also thinking at this point that we could simplify the
> description of control pragmas to eliminate any mention of "any other
> kind of pragma," and say simply:
>
> * Unless specified otherwise, a control pragma is allowed at the
> following places in a program:
That does seem simpler and more direct.
> We don't generally reference information in the Obsolescent Annex from
> the main part of the manual. We already indicate that individual
> pragmas can impose their own placement restrictions. The overall goal
> of moving features to the Obsolescent Annex is that a normal user does
> not need to be aware of anything in that Annex. So we don't want to
> imply that a normal user should refer to annex J to understand
> anything about the rest of the language.
Ok. The Annotated RM already has a Ramification with a reference to
J.15.5 (ARM 2.8(11.i/3)), and I thought an earlier general reference could be useful, but I won't insist.
From: Tucker Taft
Sent: Monday, June 05, 2023 5:40 PM (WG 9 List)
>I will of course defer to native English speakers. However, it seems to
>me that if one has a logical predicate P(X) then saying "P(X) is true
>for any X" usually means "P(X) is true for all X", and does not mean
>"P(X) is true for some X".
I would say that "any other" and "any" have quite different meanings in this context. Saying that "P(X) is true for any X" and "P(X) is true for any other X" are definitely not equivalent.
>Also, Ada quantified expressions use "some", not "any" :-)
True, but there is no "other" in that usage. ;-))
From: Randy Brukardt
Sent: Tuesday, June 06, 2023 1:45 AM (WG 9 List)
...
> - The proposed modification of 4.5.9(7/5) says that a
> declare_expression can contain an executable pragma, but cannot
> contain other kinds of pragmas. This seems to contradict the modified
> 2.8(5-8) which says that control pragmas are allowed in any place
> where any other kind of pragma is permitted, so control pragmas would
> be allowed in declare_expressions (again, assuming that "any other
> kind" should be read as "some other kind").
I don't think this conclusion is clear (either way), and as such, we will need to withdraw this AI from WG 9 consideration as well. It's not clear what we want, nor what the wording says. So we need to reconsider. (All of my grumbles about late comments apply here, too.)
[Specifically, Janus/Ada implements pragma Page and pragma List lexically; they're actually treated as invisible tokens allowed in most places. Not allowing them in declare expressions could be significant work. OTOH, allowing other control pragmas in declare expressions also could be significant work. This facility is not worth significant work for anyone. But perhaps that's unavoidable. More discussion needed.]
[a]I've removed the grey highlighting that the original author had. The HTML version of this document automatically highlights insertions and deletions in dark green and grayish red, respectively, and doing it manually conflicts with that. The automatic highlighting sometimes shows errors in insert/delete markings (including in this AI, the first insertion closing was missing!). Moreover, the manually applied gray deletions was in 5 different colors (3 grays, a green, and an orange), adding lots of unnecessary markup. As an approved AI, the need to read this editable version is much lower, so I removed all of the manual formatting.