13.   ADVANCED DEFINITIONS

This section discusses ways in which special language forms can be extended to work for data items having user-defined types. These forms include infix and prefix operators, assignment, selectors, and the case and repeat statements. Also included is a discussion of the automatically invoked initialization and finalization operations.

13.1  DEFINABLE SYMBOLS

C - identifier

Definable symbols are used to define functions for special expression forms and assignment procedures.

RULES

The operator symbols >, <=, and >= are not definable symbols.

NOTES

     Although definable symbols are defined as functions and procedures, they cannot be invoked using standard invocation forms. They are invoked only when the corresponding special syntactic form is used.

13.2  DEFINITION OF OPERATORS AND ASSIGNMENT

Users can supply definitions for the built-in prefix and infix operator symbols and for assignment. These definitions allow built-in operators to be extended to apply to data items with user-defined types.

RULES

Prefix Operators

A function with a single formal parameter and the name +, -, or NOT defines that prefix operator for a right operand having the type specified for the formal parameter.

Infix Operators

A function with two formal parameters and the name **, *, /, MOD, DIV, &, +, -, =, <, IN, AND, OR, or XOR defines that infix operator for a left operand having the type specified for the first formal parameter and a right operand having the type specified for the second formal parameter.

For the =, <, and IN infix operators, the function result must have subtype BOOL. For = and <, both formal parameters must have the same type.

Associativity

The infix operators +, *, AND, OR, XOR, and & are assumed to be associative. The expression

    a op b op c

can be evaluated as either

    (a op b) op c

or as

    a op (b op c)

where op is one of these infix operators.

Equality and Ordering

The equals (=) infix operator is assumed to define an equivalence relation. In particular, = is assumed to be reflexive (i.e., a=a is true), symmetric (i.e., a=b is equivalent to b=a) and transitive (i.e., if a=b and b=c, then a=c). The operators = and <, taken together, are assumed to define a partial order (with a total order as a special case). In particular, < is assumed to be transitive and it is assumed that, at most, one of

will be true.

The other ordering infix operators (/=, >, <=, >=) cannot be explicitly user-defined. If = is defined, then /= is also automatically defined. If < is defined, then > is also automatically defined. If both = and < are defined, then <= and >= are also automatically defined. In particular,

Assignment

A procedure with two formal parameters and the name := defines assignment. Both formal parameters must have the same type. The first formal parameter corresponds to the left hand side (i.e., the target) and the second formal parameter corresponds to the right hand side (i.e., the source).

The assignment procedure is invoked for

1. the assignment statement

2. initialization

3. CONST and OUT formal parameters

4. constructors

5. message passing via mailboxes

For assignment, the following assumptions are made:

1. Any previous value of the first parameter is lost.

2. The only value changed by assignment is the value of the first parameter

3. The value of the first parameter, after assignment, will be equal (i.e., their values can be used interchangeably) to the value of the second parameter before assignment. In particular, for types for which both := and = are defined, after elaboration of

       a := b;

   the expression

       a = b

   will have value true if a and b are non-overlapping.

Overriding Default Definitions

For new types, := and = are automatically defined (see Sections 4.4.2 and Sections 4.4.3. These automatic definitions will not occur if the user provides explicit definitions of := or = local to the same scope in which the type declaration is local.

RED RATIONALE NEED FOR USER-DEFINED ASSIGNMENT A "non-assignable" type (i.e., a type for which assignment is illegal) is easily obtained in RED, either by defining an assignment routine which raises an exception, or by not exporting the (automatically provided) assignment routine from the capsule in which the type is defined. Being able to specify an assignment routine for any new type for which the automatically provided assignment semantics would be inappropriate was included to support data abstraction. AGGREGATE ASSIGNMENT If the user defines assignment for type T, and T is used as a component in an aggregate (e.g., an array, record, or union), then the assignment automatically provided for the aggregate type will invoke the user-defined assignment for T. EXPORTING ASSIGNMENT FROM CAPSULES The issue is the following: if a type T is exported from a capsule, must assignment for T (whether system- or user-defined) be also explicitly exported, or is it exported automatically with T? RED requires explicit export of both T and its assignment operator, in the interest of avoiding unnecessary defaults. OPTIMIZATION ISSUES User-defined assignment, if not used, will not cause run-time overhead. Moreover, an attempt was made in the RED design to facilitate optimization even when user-defined assignment is used.

NOTES

     Since CONST and OUT binding depend upon =, the definition of = should not use these binding classes (if it did, infinite recursion would result).

EXAMPLES

1. Integer sets via linked lists and sharing (default) assignment

   

   
   
   

2. Integer sets via linked lists and copying (user-defined) assignment

   

   
   
   

13.3  INITIALIZATION AND FINALIZATION

When a new type is defined, it is possible to specify actions to be taken at the beginning and end of the lifetime of each new data item of that type.

RULES

When a new type is defined, the user may also define the procedures INITIALIZE and FINALIZE local to the same scope as the type definition. These procedures must each have a single formal parameter of the new type.

When a data item of the new type is created, INITIALIZE is automatically invoked. This invocation occurs prior to any explicitly specified initialization, but after the creation (and initialization) of the underlying variable or constant.

The created data item (which is considered to be variable during this invocation) is passed as the actual parameter.

Just before the end of the lifetime of a data item of the new type, FINALIZE is automatically invoked. The data item is passed as the actual parameter.

If the new type is defined within a capsule, then INITIALIZE and FINALIZE need not be exported (they must be exported only if they are to be explicitly invoked outside the capsule).

INITIALIZE and FINALIZE are not automatically called for VAR and READONLY formal parameters since these are not new variables or constants but, rather, references to existing variables or constants.

RED RATIONALE Initialization is the set of actions performed when a data item is created. A data item is considered to be created by CONST and VAR declarations, CONST and OUT formal parameter declarations, function returns, and the allocation statement. Finalization is the set of actions performed when a data item ceases to exist. A declared data item ceases to exist when an exit occurs from a scope containing the declaration; a dynamic variable ceases to exist when any pointer referencing it is FREEd, or when no pointers reference it.

NOTES

     Note that INITIALIZE and FINALIZE should not have CONST or OUT parameters (if thoy do, an infinite recursion will occur).

EXAMPLES

13.4  DEFINITION OF SELECTOR OPERATIONS

Users can define selector operations (subscripting and dot selection) for new types.

RULES

Dot Selection

The dot selection form

    primary.id

will invoke the function with name .id (which may have only a single formal parameter) and will pass primary as the only actual parameter.

Subscripting

The subscripting form

    primary(exp) will invoke the function with name (*) and will pass primary as the first actual parameter and exp as the second actual parameter. The subscripting form

    primary(exp1..exp2)

will invoke the function with name (*..*) and will pass primary as the first actual parameter and exp1 and exp2 as the second and third actual parameters.

For multiple subscripts, the name of the function invoked will correspond to the invocation form. For example,

    primary(exp1, exp2..exp3, exp4..exp5)

will involve the function with name (*, *..*, *..*). The number of formal parameters of a subscripting function must be equal to one (for the primary) plus the number of stars in its name.

RED RATIONALE To meet Steelman's requirement that the user have the ability "to declare constants and (unary) functions that may be thought of as record components and may be referenced using the same notation as for accessing record components," RED allows the user to define not just "dot qualification" but, for uniformity, subscripting and subarray selection.

EXAMPLES

1. Dot selection

   

   
   
   

2. Subscripting

   

   
   
   

13.5  DEFINITION OF RESOLUTION

Users can define the resolution form of expressions as a way of getting "literals" and "constructors" for new types.

RULES

The resolution form

    x # t

where t is a type or subtype, is treated as the invocation of the function with # and with translation time property list [t]. The expression exp is passed as the only actual parameter.

EXAMPLES

13.6  EXTENDING THE CASE STATEMENT TO USER-DEFINED TYPES

RULES

A case statement of the form

is expanded to

NOTES

     A case statement with only single value labels can be used for any type for which equality (=) is defined. A case statement with range value labels can be used for any type for which equality (=) and ordering (<) are defined.

13.7  EXTENDING THE REPEAT STATEMENT TO USER-DEFINED TYPES

RULES

A repeat statement of the form

is expanded to

A repeat statement of the form

is expanded to

NOTES

     Any user-defined subtype for which MIN, MAX, <, =, and SUCC (or PRED for the reverse form) can be used in the for phrase of a repeat statement.