. navigate
2. Lexical Structure left arrow
right arrow 4. Types
Red Reference Manual


Program     Body     Declarations     Assertions
Names and Scopes     Forward Refs to Names     Imports List



program diagram
54 - capsule declaration

A program consists of one or more translation units which may communicate with each other. Each translation unit is a capsule declaration. Capsule declarations may also be nested within translation units and are described more generally in Chapter 8. A capsule declaration consists of a header, a body, and an ending. The header names the capsule and provides an exports list that makes declarations, statements, and assertions. Declarations provide definitions for names, statements specify actions to be performed, and assertions specify conditions that are to be true at the points where the assertions appear. The ending terminates the text of the capsule declaration.

The intent of a program is realized by elaborating the program. The notion of elaboration is meant to provide a general way of describing closely related translator functions, such as execution for statements and evaluation for expressions. Elaboration can apply to statements, assertions, declarations, and expressions, and includes translation-time as well as execution-time activities. The elaboration of a compound syntactic unit is defined in terms of the elaboration of its constituent units.

In the simplest case, a program consists of just one translation unit. The invocation, initiated by the programming system, consists of elaboration of the body of that unit. When there is more than one translation unit, the user must select (via the programming system) a particular one to be invoked as the main capsule.


Elaboration of the main capsules of a system is initiated by some extra-lingual facility (e.g., the operating system, the computer operator, or the power up sequencing hardware). A capsule which is not a main capsule must be referenced from some other capsule in order to be useful. In order for a capsule (or its exported objects) to be referenced, its name must be visible. When two capsules are translated together, name visibility is provided by the standard scope rules. When the capsules are translated separately, the scope rules must be extended to provide the required visibility.


program example

3.2  BODY

body diagram
4 - declaration   8 - assertion   36 - statement  

A body consists of a sequence of body elements, each of which is either a declaration, a statement, or an assertion. A body is used where a related sequence of body elements must be treated as a unit. Statements and declarations that can contain bodies are known as compound statements and compound declarations. For example, one possible form of an if statement is:

body example 1

In this example, body1 and body2 specify the actions to be taken after elaboration of the expression yields true or false, respectively. Depending on the bodies given, the actions may range from elaboration of a single element to a complex sequence of actions.

Empty bodies are permissible; this is useful when no action needs to be taken.


An immediate declaration (see Section 3.3) must precede all statements. A deferred declaration (see Section 3.3) or generic declaration (see Section 11.3) may either precede or follow all statements.

Elaboration of a body consists of the elaboration of all body elements other than deferred and generic declarations. The elements are elaborated in the sequence in which they are written, unless control is transferred by an exit, return, or goto statement.


     A body is an open scope (see Section 3.5). Declarations and goto labels define names within a body.

    An assertion may appear at any point in the sequence of body elements since it may be useful before or after either a declaration or a statement.

    Since deferred declarations and generic declarations are sometimes quite long, placing them after the statements often makes a program more readable. Placement of deferred declarations can be determined by programming standards and style considerations.


declaration diagram
15 - variable declaration   16 - constant declaration   17 - abbreviation declaration   19 - type declaration
48 - procedure declaration   50 - function declaration   54 - capsule declaration   55 - capsule invocation declaration
57 - exception declaration   61 - task declaration   69 - generic declaration

All declarations define names. There are two basic kinds of declarations: immediate and deferred. Immediate declarations are elaborated when encountered during the elaboration of a body. Deferred declarations are not elaborated when first encountered; instead, they define deferred units which are elaborated only when invoked from elsewhere.

A genereic declaration stands for a collection of deferred declarations and, therefore, is not elaborated when encountered (see Section 11) for a discussion of generics.


     Differences between immediate and deferred declarations> are listed below.

Immediate declaration Deferred declaration
elaborated when encountered     elaborated when invoked
can not have parameters can have parameters (7.3)
must appear before statements        can appear either before or
after statements (3.2)
can not be overloaded explicit overloading is permitted
for all except types (11.2)
can not be generic can be generic (11.3)
can not have a translation
time property list
can have a translation time
property list (11.1.2)
are not compound includes all compound declarations
are not scopes are closed scopes (3.5)

     Deferred declarations and their characteristics are summarized below.

Declaration Invocation Effect of Invocation
procedure (7.1)     procedure invocation    
performs some action
function (7.2)     function invocation    
produces a value
task (10.1)     task invocation    
an activation of the task
is elaborated concurrently
capsule (8.1)     capsule invocation    
makes exported definitions
abbreviation (4.4.1)        abbreviation
produces an abbreviated
type or subtype
type (4.4.2)     user-defined subtype           produces a subtype of
a user-defined type


1) Immediate declarations.

immediate declaration example

2) Deferred declarations.

deferred declaration example

2) Generic declaration.

generic declaration example


assertions diagram
26 - expression

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.


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.


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


assertion example


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.


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:

  1. all local definitions; and

  2. 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:

  1. goto labels and matching identifiers; and

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


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


name and scope example


Use of a variable or constant name before it has been created is not permitted.


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.


     Forward references to deferred definitions, goto labels, and exceptions are always allowed.


1) Legal forward reference to a deferred declaration.

forward reference example

2) Correct uses and incorrect forward references to immediate declarations.

incorrect forward reference example


imports list diagram
C - identifier

A compound declaration (procedure, function, task, or capsule) may include an imports list. The imports list specifies that certain variables, known in the enclosing scope, are to be made available in the compound declaration. A variable imported into a compound declaration can be restricted so that it cannot be modified inside the compound declaration.


Every name in the imports list of a compound declaration must be associated with a variable definition (see Section 4.2) known in the immediately enclosing scope.

If ALL is specified, all variable definitions which are known in the enclosing scope are available to the compound declaration (see Section 3.5).

If a list of names is specified, the definitions associated with those names are available to the compound declaration.

If READONLY precedes a name, that variable is treated as a readonly data item within the compound declaration (see Section 4.2).

Program     Body     Declarations     Assertions
Names and Scopes     Forward Refs to Names     Imports List

2. Lexical Structure left arrow
right arrow 4. Types



RED Reference
RED Rationale

Types in RED
Time/Life Computer Languages

Site Index

Overview             Reference ToC             Rationale ToC             Site Index

Home   Favorites   Map

IME logo Copyright © 2009, Mary S. Van Deusen