A pragma is a compiler directive.
There are language-defined pragmas that give instructions for optimization,
listing control, etc. An implementation may support additional (implementation-defined)
Language Design Principles
In general, if all pragma
are treated as unrecognized pragma
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
obey this principle both syntactically and semantically, so that if the
not recognized by some other implementation, the program will remain
are only allowed at the following places in a program:
At any place where the syntax rules allow a construct defined by a syntactic
category whose name ends with “declaration
”, or “alternative
or one of the syntactic categories variant
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.
Additional syntax rules and placement restrictions
exist for specific pragmas.
The above rule is written
in text, rather than in BNF; the syntactic category pragma
is not used in any BNF syntax rule.
To be honest:
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
An identifier specific to
is an identifier or reserved word that is used in a pragma
argument with special meaning for that pragma.
To be honest:
Whenever the syntax rules
for a given pragma allow "identifier
as an argument of the pragma
is an identifier specific to that pragma.
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
(the reserved word(s) are not shown). For example, the restriction No_Use_Of_Attribute
) allows the reserved words
which can be attribute designators, but the syntax for a restriction
does not include these reserved words.
If an implementation does not recognize the name
of a pragma
then it has no effect on the semantics of the program. Inside such a
only rules that apply are the Syntax Rules.
To be honest: This rule takes precedence
over any other rules that imply otherwise.
Note well: this rule applies
only to pragma
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
not cause freezing, even though the rules in 13.14
” 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
implementation defined. For example: “pragma
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
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.
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
”). 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.
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.
For a pragma
that appears at the place of an elaborable construct, execution is elaboration.
An identifier specific to a pragma is neither
— such identifiers are not evaluated (unless an implementation
defines them to be evaluated in the case of an implementation-defined
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 pragma
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.
The implementation shall give a warning message for
an unrecognized pragma name.
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.
An implementation may provide implementation-defined
pragmas; the name of an implementation-defined pragma shall differ from
those of the language-defined pragmas.
Implementation defined: Implementation-defined
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.
An implementation may ignore an unrecognized pragma
even if it violates some of the Syntax Rules, if detecting the syntax
error is too complex.
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.
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.
Implementation Advice: Implementation-defined
pragmas should have no semantic effect for error-free programs.
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.
Normally, an implementation
should not define pragmas that can make an illegal program legal, except
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.
used to configure the environment by adding, removing, or replacing library_item
pragmas should not make an illegal program legal, unless they complete
a declaration or configure the library_item
in an environment.
For example, it is OK to
support Interface, System_Name, Storage_Unit, and Memory_Size pragma
for upward compatibility reasons, even though all of these pragma
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
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.
Incompatibilities With Ada 83
In Ada 83, “bad”
ignored. In Ada 95, they are illegal, except in the case where the name
of the pragma
itself is not recognized by the implementation.
Extensions to Ada 83
may affect the legality of a program.
Wording Changes from Ada 83
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
Extensions to Ada 2005
Identifiers specific to a pragma can be reserved words.
Pragma arguments can be identified with aspect_mark
this allows identifier
in this context. As usual, this is only allowed if specifically allowed
by a particular pragma.
Wording Changes from Ada 2005
Wording Changes from Ada 2012
Added wording to ensure that pragmas
are not allowed in declare_expressions.
We don't allow this as the definition of most pragmas assume that they're
given between entities. We also don't want to answer questions about
conformance of pragmas,
especially unrecognized pragmas
whose state can change between the specification and body.
The forms of List,
Page, and Optimize pragma
are as follows:
[Other pragmas are defined throughout this International
Standard, and are summarized in Annex L
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.
List takes one of the identifier
On or Off as the single argument. This pragma is allowed anywhere a pragma
is allowed. It specifies that listing of the compilation is to be continued
or suspended until a List pragma
with the opposite argument is given within the same compilation. The
is always listed if the compiler is producing a listing.
Page is allowed anywhere a pragma
is allowed. It specifies that the program text which follows the pragma
should start on a new page (if the compiler is currently producing a
Optimize takes one of the identifier
Time, Space, or Off as the single argument. This pragma
is allowed anywhere a pragma
is allowed, and it applies until the end of the immediately enclosing
declarative region, or for a pragma
at the place of a compilation_unit
to the end of the compilation
It gives advice to the implementation as to whether time or space is
the primary optimization criterion, or that optional optimizations should
be turned off. [It is implementation defined how this advice is followed.]
Implementation defined: Effect of pragma
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.
Examples of pragmas:
List(Off); -- turn off listing generation
Optimize(Off); -- turn off optional optimizations
Pure(Rational_Numbers); -- set categorization for package
Message => "Nonexistent file"); -- assert file exists
Extensions to Ada 83
The Optimize pragma
now allows the identifier Off to request that normal optimization be
An Optimize pragma
may appear anywhere pragmas are allowed.
Wording Changes from Ada 83
We now describe the pragmas Page, List, and
Optimize here, to act as examples, and to remove the normative material
from Annex L
”, so it can be entirely an informative annex.
Wording Changes from Ada 95
Updated the example of named pragma parameters, because the second parameter
Suppress is obsolescent.
Wording Changes from Ada 2005
Updated the example of pragmas, because both pragma
Inline and Import are obsolescent.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe