Contents Index 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
return_statement ::= return [expression];
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
- A vertical line separates alternative items unless it occurs
immediately after an opening curly bracket, in which case it stands for
itself:
13
constraint ::= scalar_constraint | composite_constraint
discrete_choice_list ::= discrete_choice {| discrete_choice}
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 the RM95 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.
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
Ramification: For example,
an expression is a construct. A
declaration is a construct, whereas the thing declared by a declaration
is an ``entity.''
16.b
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 non-technical 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 run-time 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
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
3 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
4 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.
Contents Index Previous Next Legal