An assertion specifies a condition which will be true when the assertion is elaborated. Assertions
are used to make programs easier to read and maintain, to provide information useful to an optimizing
compiler, and to provide checkpoints for formal and informal verification of correctness.
RULES
The expression must have type BOOL. Elaboration of an assertion consists of testing the value of
the expression and, if the expression is false, raising the X-ASSERT exception.
NOTES
An assertion does not necessarily imply run-time checking. If the condition can be checked during translation, then
object code need not be generated for it. if an assertion is known to be false at translation time, a warning is issued.
A pragmat is available for suppressing the X-ASSERT exception (see Appendix B).
EXAMPLES
3.5 NAMES AND SCOPES
A name is either an identifier or a definable symbol
(see Section 13.2). Definable symbols are
used only to refer to built-in operations or to functions and procedures that
provide additional definitions for
built-in operations.
Every use of a name must have a corresponding definition; definitions of names are never
created by default. There are several forms of definition, including declarations, formal parameters, and
goto labels. A name may have more than one definition; when this occurs, it must be possible to
associate each use with the
appropriate definition. The association is governed by the scoping rules.
A scope is a syntactic form in which names may be defined.
An open scope is a scope in which all
definitions in the enclosing scope are known, provided that those definitions do not conflict with a
local definition of the open scope. A closed scope differs from an open scope in that matching
identifiers (the target of an exit statement) and goto labels (see Chapter 6)
from the enclosing scope
are never available and variables from the enclosing scope are available only when
explicitly listed in an imports list.
RULES
All deferred declarations (see Section 3.3) are closed scopes. Bodies
(see Section 3.2),
compound statements (see Chapter 6), and generic declarations
(see Section 11.3) are open scopes.
Everything in one scope that is outside any scope contained within it, is called local to that scope.
For all non-deferred definitions, two definitions are considered to conflict if the same name is
associated with both. Conflicting definitions local to the same scope are not permitted.
Deferred declarations with the same name do not necessarily conflict (see Section 11.1).
The definitions which are known in a scope are:
- all local definitions; and
- each definition which is known in the enclosing scope, is available,
and does not conflict with a local definition.
For open scopes, all definitions known in the enclosing scope are available. For closed scopes, all
definitions known in the enclosing scope are also available, with the following two exceptions:
- goto labels and matching identifiers; and
- variable definitions, that are not explicitly
imported (see Section 3.7)
Any occurrence of a name other than a defining occurrence is a use of that name. A use of a
name which is local to some scope must correspond to a definition which is known in that scope. Each
use must correspond to exactly one definition. For names other than names of
deferred units, at most one definition of a name will be known in each scope.
NOTES
Definitions which are exposed in e scope (eee Section 8.2) are considered to be local definitions of that scope.
Uses of names local to some scope are uniformly associated with definitions; i.e., the definition associated
with a particular use
is the same, no matter where within the scope that use occurs.
Conflicting definitions of a single name can exist in different scopes without restriction.
Conflicting definitions of a single
name within a single scope are excluded since this would make it impossible to associate each use uniquely to a
single definition.
A definition may be any of the following: a declaration (see 3.3), a formal parameter
(see 7.3), a goto label (see 8), the index
of a repeat statement (see 6.5), a matching identifier (see 6),
a formal parameter (see 7.3), a generic parameter (see 11.3), or a
needed name (see 11.4).
EXAMPLES
3.6 FORWARD REFERENCES T0 NAMES
Use of a variable or constant name before it has been created is not permitted.
RULES
No use of a name defined as a variable or constant can appear before its definition.
A deferred unit is said to require a variable or constant if it either contains a use of the
name of the variable or constant or contains an invocation of some other deferred unit that requires that
variable or constant. No invocation of a deferred unit that requires a variable or constant may appear
before the definition of that variable or constant.
NOTES
Forward references to deferred definitions, goto labels, and exceptions are always allowed.
EXAMPLES
1) Legal forward reference to a deferred declaration.
2) Correct uses and incorrect forward references to immediate declarations.
Copyright © 2009, Mary S. Van Deusen
