Annotated Ada Reference Manual (Ada 202y Draft 1)Legal Information
Contents   Index   References   Search   Previous   Next 

1.1.4 Method of Description and Syntax Notation

1
The form of an Ada program is described by means of a context-free syntax together with context-dependent requirements expressed by narrative rules.
2
The meaning of Ada programs is described by means of narrative rules defining both the effects of each construct and the composition rules for constructs.
3
The context-free syntax of the language is described using a simple variant of Backus-Naur Form. In particular: 
4
Lower case words in a sans-serif font, some containing embedded underlines, are used to denote syntactic categories, for example: 
5
case_statement
6
Boldface words are used to denote reserved words, for example: 
7
array
8
Square brackets enclose optional items. Thus the two following rules are equivalent. 
9/2
{AI95-00433-01} simple_return_statement ::= return [expression];
simple_return_statement ::= return; | return expression;
10
Curly brackets enclose a repeated item. The item may appear zero or more times; the repetitions occur from left to right as with an equivalent left-recursive rule. Thus the two following rules are equivalent. 
11
term ::= factor {multiplying_operator factor}
term ::= factor | term multiplying_operator factor
12/5
{AI12-0212-1} A vertical line separates alternative items, for example: 
13/5
{AI12-0212-1} constraint ::= scalar_constraint | composite_constraint
13.1/5
{AI12-0212-1} For symbols used in this notation (square brackets, curly brackets, and the vertical line), the symbols when surrounded by ' represent themselves, for example: 
13.2/5
{AI12-0212-1} discrete_choice_list ::= discrete_choice {'|' discrete_choice}
named_container_aggregate ::= '[' container_element_association_list ']'
14
If the name of any syntactic category starts with an italicized part, it is equivalent to the category name without the italicized part. The italicized part is intended to convey some semantic information. For example subtype_name and task_name are both equivalent to name alone. 
14.a
Discussion: The grammar given in this document is not LR(1). In fact, it is ambiguous; the ambiguities are resolved by the overload resolution rules (see 8.6).
14.b
We often use “if” to mean “if and only if” in definitions. For example, if we define “photogenic” by saying, “A type is photogenic if it has the following properties...”, we mean that a type is photogenic if and only if it has those properties. It is usually clear from the context, and adding the “and only if” seems too cumbersome.
14.c
When we say, for example, “a declarative_item of a declarative_part”, we are talking about a declarative_item immediately within that declarative_part. When we say “a declarative_item in, or within, a declarative_part”, we are talking about a declarative_item anywhere in the declarative_part, possibly deeply nested within other declarative_parts. (This notation doesn't work very well for names, since the name “of” something also has another meaning.)
14.d
When we refer to the name of a language-defined entity (for example, Duration), we mean the language-defined entity even in programs where the declaration of the language-defined entity is hidden by another declaration. For example, when we say that the expected type for the expression of a delay_relative_statement is Duration, we mean the language-defined type Duration that is declared in Standard, not some type Duration the user might have declared. 
14.1/3
  {AI95-00285-01} {AI05-0004-1} {AI05-0262-1} The delimiters, compound delimiters, reserved words, and numeric_literals are exclusively made of the characters whose code point is between 16#20# and 16#7E#, inclusively. The special characters for which names are defined in this document (see 2.1) belong to the same range. [For example, the character E in the definition of exponent is the character whose name is “LATIN CAPITAL LETTER E”, not “GREEK CAPITAL LETTER EPSILON”.] 
14.e/2
Discussion: This just means that programs can be written in plain ASCII characters; no characters outside of the 7-bit range are required. 
14.2/5
  {AI95-00395-01} {AI05-0227-1} {AI05-0299-1} {AI12-0263-1} {AI12-0450-1} When this document mentions the conversion of some character or sequence of characters to upper case, it means the character or sequence of characters obtained by using simple upper case mapping, as defined by documents referenced in Clause 2 of ISO/IEC 10646:2020. 
14.f/5
Implementation Note: {AI12-0263-1} The “documents referenced” means Unicode, Chapter 4 (specifically, section 4.2 — Case). Machine-readable versions of Simple Uppercase Mapping and Simple Lowercase Mapping can be found in http://www.unicode.org/Public/UCD/latest/ucd/UnicodeData.txt. Data for older Unicode versions can be found on this site as well; start at http://www.unicode.org/Public/ and find the appropriate version number. Simple Uppercase Mapping is the 12th field in this file (the 13th element of each line, since Unicode counts from 0); the Simple Lowercase Mapping is the 13th field in this file. In both cases, if no character is present in the field, the character maps to itself. 
15
A syntactic category is a nonterminal in the grammar defined in BNF under “Syntax”. Names of syntactic categories are set in a different font, like_this.
16
A construct is a piece of text (explicit or implicit) that is an instance of a syntactic category defined under “Syntax”. 
16.a/5
Term entry: construct — piece of text (explicit or implicit) that is an instance of a syntactic category defined under Syntax
16.b
Ramification: For example, an expression is a construct. A declaration is a construct, whereas the thing declared by a declaration is an “entity”. 
16.c
Discussion: “Explicit” and “implicit” don't mean exactly what you might think they mean: The text of an instance of a generic is considered explicit, even though it does not appear explicitly (in the nontechnical sense) in the program text, and even though its meaning is not defined entirely in terms of that text. 
17
A constituent of a construct is the construct itself, or any construct appearing within it.
18
Whenever the run-time semantics defines certain actions to happen in an arbitrary order, this means that the implementation shall arrange for these actions to occur in a way that is equivalent to some sequential order, following the rules that result from that sequential order. When evaluations are defined to happen in an arbitrary order, with conversion of the results to some subtypes, or with some runtime checks, the evaluations, conversions, and checks may be arbitrarily interspersed, so long as each expression is evaluated before converting or checking its value. [Note that the effect of a program can depend on the order chosen by the implementation. This can happen, for example, if two actual parameters of a given call have side effects.] 
18.a
Discussion: Programs will be more portable if their external effect does not depend on the particular order chosen by an implementation. 
18.b
Ramification: Additional reordering permissions are given in 11.6, “Exceptions and Optimization”.
18.c
There is no requirement that the implementation always choose the same order in a given kind of situation. In fact, the implementation is allowed to choose a different order for two different executions of the same construct. However, we expect most implementations will behave in a relatively predictable manner in most situations. 
18.d
Reason: The “sequential order” wording is intended to allow the programmer to rely on “benign” side effects. For example, if F is a function that returns a unique integer by incrementing some global and returning the result, a call such as P(F, F) is OK if the programmer cares only that the two results of F are unique; the two calls of F cannot be executed in parallel, unless the compiler can prove that parallel execution is equivalent to some sequential order. 
19
NOTE 1   The syntax rules describing structured constructs are presented in a form that corresponds to the recommended paragraphing. For example, an if_statement is defined as: 
20
if_statement ::=
    if condition then
      sequence_of_statements
   {elsif condition then
      sequence_of_statements}
   [else
      sequence_of_statements]
    end if;
21
NOTE 2   The line breaks and indentation in the syntax rules indicate the recommended line breaks and indentation in the corresponding constructs. The preferred places for other line breaks are after semicolons. 

Wording Changes from Ada 95

21.a/2
{AI95-00285-01} We now explicitly say that the lexical elements of the language (with a few exceptions) are made up of characters in the lower half of the Latin-1 character set. This is needed to avoid confusion given the new capability to use most ISO 10646 characters in identifiers and strings.
21.b/2
{AI95-00395-01} We now explicitly define what the Reference Manual means by upper case, as there are many possibilities for ISO 10646 characters.
21.c/2
{AI95-00433-01} The example for square brackets has been changed as there is no longer a return_statement syntax rule. 

Wording Changes from Ada 2005

21.d/3
{AI05-0227-1} Correction: Upper case is defined by "simple upper case mapping", because "full case folding" is a mapping (mostly) to lower case. 

Wording Changes from Ada 2012

21.e/5
{AI12-0212-1} Changed the syntax description to quote symbols used in the notation when they appear as themselves. We made this change to allow square brackets in Ada syntax, but the change also allowed us to get rid of an old hack which allowed vertical lines to stand for themselves in limited circumstances.

Contents   Index   References   Search   Previous   Next 
Ada-Europe Ada 2005 and 2012 Editions sponsored in part by Ada-Europe