2.8 Pragmas

{AI05-0100-1} {AI05-0163-1} In general, if all pragmas are 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 not recognized by some other implementation, the program will remain legal. 

Discussion: The above rule is written in text, rather than in BNF; the syntactic category pragma is not used in any BNF syntax rule. 

Ramification: A pragma is allowed where a generic_formal_parameter_declaration is allowed. 

To be honest: {AI95-00284-02} For compatibility with Ada 83, the name of a pragma may also be “interface”, which is not an identifier (because it is a reserved word). See J.12.

To be honest: Whenever the syntax rules for a given pragma allow "identifier" as an argument of the pragma, that identifier is an identifier specific to that pragma.

{AI05-0272-1} In a few cases, a reserved word is allowed as "an identifier specific to a pragma". Even in these cases, the syntax still is written as identifier (the reserved word(s) are not shown). For example, the restriction No_Use_Of_Attribute (see 13.12.1) allows the reserved words which can be attribute designators, but the syntax for a restriction does not include these reserved words. 

To be honest: This rule takes precedence over any other rules that imply otherwise. 

Ramification: Note well: this rule applies only to pragmas whose name is not recognized. If anything else is wrong with a pragma (at compile time), the pragma is illegal. This is true whether the pragma is language defined or implementation defined.

For example, an expression in an unrecognized pragma does not cause freezing, even though the rules in 13.14, “Freezing Rules” say it does; the above rule overrules those other rules. On the other hand, an expression in a recognized pragma causes freezing, even if this makes something illegal.

For another example, an expression that would be ambiguous is not illegal if it is inside an unrecognized pragma.

Note, however, that implementations have to recognize pragma Inline(Foo) and freeze things accordingly, even if they choose to never do inlining.

Obviously, the contradiction needs to be resolved one way or the other. The reasons for resolving it this way are: The implementation is simple — the compiler can just ignore the pragma altogether. The interpretation of constructs appearing inside implementation-defined pragmas is implementation defined. For example: “pragma Mumble(X);”. If the current implementation has never heard of Mumble, then it doesn't know whether X is a name, an expression, or an identifier specific to the pragma Mumble. 

To be honest: The syntax of individual pragmas overrides the general syntax for pragma.

Ramification: Thus, an identifier specific to a pragma is not a name, syntactically; if it were, the visibility rules would be invoked, which is not what we want.

{AI05-0229-1} This also implies that named associations do not allow one to give the arguments in an arbitrary order — the order given in the syntax rule for each individual pragma must be obeyed. However, it is generally possible to leave out earlier arguments when later ones are given; for example, this is allowed by the syntax rule for pragma Import (see J.15.5, “Interfacing Pragmas”). As for subprogram calls, positional notation precedes named notation.

Note that Ada 83 had no pragmas for which the order of named associations mattered, since there was never more than one argument that allowed named associations. 

To be honest: The interpretation of the arguments of implementation-defined pragmas is implementation defined. However, the syntax rules have to be obeyed. 

Ramification: For a pragma that appears at the place of an elaborable construct, execution is elaboration.

An identifier specific to a pragma is neither a name nor an expression — such identifiers are not evaluated (unless an implementation defines them to be evaluated in the case of an implementation-defined pragma).

The “unless otherwise specified” part allows us (and implementations) to make exceptions, so a pragma can contain an expression that is not evaluated. Note that pragmas in type_definitions may contain expressions that depend on discriminants.

When we wish to define a pragma with some run-time effect, we usually make sure that it appears in an executable context; otherwise, special rules are needed to define the run-time effect and when it happens. 

Ramification: An implementation is also allowed to have modes in which a warning message is suppressed, or in which the presence of an unrecognized pragma is a compile-time error. 

Implementation defined: Implementation-defined pragmas.

Ramification: The semantics of implementation-defined pragmas, and any associated rules (such as restrictions on their placement or arguments), are, of course, implementation defined. Implementation-defined pragmas may have run-time effects. 

Reason: Many compilers use extra post-parsing checks to enforce the syntax rules, since the Ada syntax rules are not LR(k) (for any k). (The grammar is ambiguous, in fact.) This paragraph allows them to ignore an unrecognized pragma, without having to perform such post-parsing checks. 

Implementation Advice: Implementation-defined pragmas should have no semantic effect for error-free programs.

Ramification: Note that “semantics” is not the same as “effect;” as explained in 1.1.3, the semantics defines a set of possible effects.

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. 

Discussion: {AI05-0229-1} There are no language-defined pragmas which can be completions; pragma Import was defined this way in Ada 95 and Ada 2005, but in Ada 2012 pragma Import just sets aspect Import which disallows having any completion.

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.

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.)

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. 

In Ada 83, “bad” pragmas are ignored. In Ada 95, they are illegal, except in the case where the name of the pragma itself is not recognized by the implementation. 

Implementation-defined pragmas may affect the legality of a program. 

Implementation-defined pragmas may affect the run-time semantics of the program. This was always true in Ada 83 (since it was not explicitly forbidden by RM83), but it was not clear, because there was no definition of “executing” or “elaborating” a pragma.

{AI05-0163-1} Correction: Allow pragmas in place of a statement, even if there are no other statements in a sequence_of_statements.

{AI05-0272-1} Identifiers specific to a pragma can be reserved words.

{AI05-0290-1} Pragma arguments can be identified with aspect_marks; this allows identifier'Class in this context. As usual, this is only allowed if specifically allowed by a particular pragma. 

{AI05-0100-1} Correction: Clarified where pragmas are (and are not) allowed. 

Ramification: The language-defined pragmas are supported by every implementation, although “supporting” some of them (for example, Inline) requires nothing more than checking the arguments, since they act only as advice to the implementation. 

Implementation defined: Effect of pragma Optimize.

Discussion: For example, a compiler might use Time vs. Space to control whether generic instantiations are implemented with a macro-expansion model, versus a shared-generic-body model.

We don't define what constitutes an “optimization” — in fact, it cannot be formally defined in the context of Ada. One compiler might call something an optional optimization, whereas another compiler might consider that same thing to be a normal part of code generation. Thus, the programmer cannot rely on this pragma having any particular portable effect on the generated code. Some compilers might even ignore the pragma altogether. 

The Optimize pragma now allows the identifier Off to request that normal optimization be turned off.

An Optimize pragma may appear anywhere pragmas are allowed. 

We now describe the pragmas Page, List, and Optimize here, to act as examples, and to remove the normative material from Annex L, “Language-Defined Pragmas”, so it can be entirely an informative annex. 

{AI95-00433-01} Updated the example of named pragma parameters, because the second parameter of pragma Suppress is obsolescent. 

{AI05-0229-1} Updated the example of pragmas, because both pragmas Inline and Import are obsolescent.