11.   OVERLOADING AND GENERICS

Overloading is the association of a single name with multiple deterred units of the same kind. A name could be associated with several different procedures, for example, but not with a procedure and a function. All deferred units associated with a single overloaded name will normally perform logically related computations. For example, the overloaded name ABS is associated both with a built-in function for finding the absolute value of an integer and with another built-in function for finding the absolute value of a floating point number.

Interfaces are used to match each use of an overloaded name, during translation, to a particular deferred unit associated with that name.

In the simplest case, interfaces depend only upon a signature which includes the number, order, and types of a list of parameters. The use of an overloaded name in an invocation will be resolved to the deferred unit which has a matching signature; that is, the number, order, and types for the actual parameters are identical to the number, order and types for the formal parameters. For example,

In addition to the signature, interfaces can depend upon a translation time property list specified by a list enclosed in square brackets

The information which is considered to be part of the interface depends upon the kind of deferred unit. For types, the translation time property list is the entire interface (signatures are not part of the interface for types). For other deferred units, the interface consists of both the translation time property list (if specified) and the signature.

There are two kinds of overloading: explicit overloading and generic overloading. Explicit overloading occurs when several distinct definitions of a name are written. Explicit overloading can be used for any kind of deferred unit except types. Generic overloading occurs when a single deferred declaration is replicated as a result of its appearance within a generic declaration. Generic overloading can be used for any kind of deferred unit.

RED RATIONALE All typed languages provide a certain degree of overloading. At the very least, operations like + are overloaded for built-in types. In languages with user-defined abstract types, some means of permitting two types to have the same operation is required. In RED, the declaration and invocation of an overloaded routine have the same form as for a non-overloaded routine, and the selection of the invoked routine is done in a simple manner. Furthermore, selection can always be done at translation time, since it is based on type information.

NOTES

     Names associated with variables, constants, exceptions, goto labels, or matching identifiers cannot be overloaded.

11.1  INTERFACES

Interfaces are used to resolve each use of an overloaded name to one of the deferred units associated with that name. Interfaces include signatures (for all deferred units except types) and translation time property lists (if specified).

RULES

Each definition of a deferred unit has a formal interface. Each invocation of a deferred unit has an actual interface.

Each use of the (possibly overloaded) name of a deferred unit is resolved to the deferred unit associated with the name whose formal interface matches the actual interface of the use. If there is no such deferred unit, the use is in error.

Any two definitions of a name conflict unless

1. They are both deferred units of the same kind, and

2. Their interfaces do not match.

The interface of a procedure, function, task, abbreviation, or capsule consists of a signature and, if specified, the translation time property list. The interface of a capsule or type consists of a translation time property list if any is specified.

Two interfaces match if:

1. Both have matching signatures or neither includes a signature, and

2. Both have matching translation time property lists or neither includes a translation time property list.

NOTES

     Matching of interfaces is done during translation.

     The scope rules (see Section 3.5) permit a local definition to override a conflicting definition in an enclosing scope; that is, one deferred declaration will override another deferred declaration in an enclosing scope if they have matching interfaces. A local declaration of one kind will override all declarations of another kind when all share the same name.

EXAMPLES

1. No signature and no translation time property list

   

   
   
   

2. Signature and no translation time property list

   

   
   
   

3. Translation time property list but no signature

   

   
   
   

4. Both a signature and a translation time property list

   

   
   
   

11.1.1  SIGNATURES

A signature is part of the interface between any deferred unit except a type and its invocations. Signatures are derived from the formal and actual parameter lists, and are not explicitly specified.

RULES

The formal signature of a procedure, function, task, abbreviation, or capsule is an ordered list of the types or subtypes specified for its formal parameters. The list is empty if it has no formal parameters.

The actual signature of a procedure, function, task, abbreviation, or capsule invocation ls an ordered list of the subtypes of its actual parameters. if there are no actual parameters, the list ls empty.

Two signatures match if their lists are the same length and each of their elements match. Two types match if they are equal (see Section 4.1.5). Two subtypes match if they belong to the same type. A type and a subtype match if the subtype belongs to the type.

NOTES

     Function result types or subtypes are not considered to be part of a signature.

EXAMPLES

11.1.2  TRANSLATION TIME PROPERTY LIST

C - identifier   10 - type   12 - subtype   26 - expression   81 - definable symbol

A translation time property list, if present, is part of the interface between a deferred unit and its invocations. If a formal translation time property list is included in a deferred unit, each of the invocations must specify a matching actual translation time property list. Translation time property lists are always explicitly specified.

RULES

Each expression must be manifest and must be of a type for which equality (=) is defined. Each identifier must be the name of a function, procedure, or task. The identifier may be followed by an actual translation time property list only when it appears as a property in an actual generic property list. Definabie symbols may only appear in an actual generic property list.

Two translation time property lists match if they have the same number of properties and if their corresponding properties match. Two expressions match if their values are equal. Two types match if they are equal (see Section 4.1.5). Two subtypes match if they belong to the same type. A type and a subtype match if the subtype belongs to the type. An identifier matches an actual property if they both refer to the same procedure, function, or task.

EXAMPLES

11.2  EXPLICIT OVERLOADING

Explicit overloading occurs when there are several distinct definitions of deferred units of the same kind, each of which has the same name, but a different interface.

RULES

Explicit overloading can be used for any kind of deferred unit except types.

EXAMPLES

11.3  GENERIC DECLARATION

C - identifier   10 - type   12 - subtype   26 - expression   81 - definable symbol

A deferred declaration can be "generalized" by placing it in a generic declaration and by replacing specific types, subtypes, or procedure or function names by references to generic parameters. For example, a sort procedure which sorts arrays with integer components can be easily generalized to a generic sort procedure which will sort arrays with any component type.

RULES

The deferred declaration is called the pattern declaration and defines the overloaded name.

The interface of the pattern declaration must contain a use of each generic parameter. The use can be

1. within the formal translation time property list, or

2. within in the formal signature, or

3. in the generic constraint of some other generic parameter that has a use in the lhterface. The use cannot appear as a result type or subtype of a FUNC operation constraint.

lf a generic parameter appears more than once in the formal interface, each of the corresponding places in an actual interface must resolve the generic parameter to the same replacement element.

The generic declaration is replaced during translation by a set of deferred declarations called the generated set.

Each deferred declaration in the generated set is obtained first by copying the pattern declaration, and then substituting a specific replacement element for each generic parameter and for each needs list definition.

If the overloaded name is never invoked, then the generated set is empty. Otherwise, each invocation of the overloaded name is examined. Each invocation of the overloaded name will have an actual interface which will be used to set a replacement element for each generic parameter. Needed definitions are set to corresponding definitions known in the scope of invocation (see Section 11.4). A new copy of the pattern declaration, with replacement elements for its generic parameters and for each needs list definition, is added to the generated set if no equivalent copy has been added previously, as a result of examining some other invocation.

If a generic declaration is capable of generating some deferred declaration that conflicts with a particular definition, then the generic declaration itself is considered to conflict with that definition. The conflict exists even though the deferred declaration is not actually generated.

RED RATIONALE Generics in RED have aspects of both routines and macros. Like routines, a definition environment supplies the interpretation of all non-local identifiers. Also like routines, the values of actual parameters (not the names) are passed. However, generics resemble macros in that they are instantiated at translation time to produce the actual entity that is used at run time. Instantiation can occur at translation time because all the actuals are manifest.

NOTES

     A generic declaration is an open scope; the generic parameters and the needs list items arc defined in this scope.

11.3.1  TYPE GENERIC CONSTRAINTS

C - identifier

A generic parameter with a type generic constraint has replacement elements which are types.

RULES

Any type (including those not known in the scope of the generic declaration) may be a replacement element for a generic parameter whose generic constraint is TYPE.

Any type whose name is td and is known in the scope of the generic declaration can be a replacement element for a generic parameter whose generic constraint is TYPE (..., id,...).

RED RATIONALE Usually type generic parameters will be used to stand for any arbitrary type, but forms are also provided to require that the type generic parameter be limited to one of a number of listed types, or to be a type from a particular category (e.g., enumeration).

EXAMPLES

11.3.2  SUBTYPE GENERIC CONSTRAINTS

C - identifier   10 - type

A generic parameter with a subtype generic constraint has replacement elements which are subtypes.

RULES

Any subtype (including those whose types are not known in the scope of a generic declaration) can be used as replacement elements for a generic parameter whose generic constraint is SUBYYPE.

Any subtype ot type t may be used as a replacement element for a generic parameter whose generic constraint is SUBTYPE (...,t,...).

Any subtype whose type has the name id and is known in the scope of the generic declaration can be used as a replacement element of a generic parameter whose generic constraint is SUBTYPE (...,id,...).

If a subtype is used in several places within the formal intertace, then the actual interface must specify the same subtype in each of the corresponding places. Otherwise, the X_SUBTYPE exception is raised when the invocation is elaborated.

NOTES

     For interface matching, only the type of subtypes is used. Subtype information is used to set generic parameters with a subtype generic constraint, as well as to check for consistency of subtypes (X_SUBTYPE checking).

EXAMPLES

11.3.3  OPERATION GENERIC CONSTRAINTS

10 - type   12 - subtype

An operation generic constraint has replacement elements which are either procedures, functions, or tasks. In each case, the types or subtypes of the formal parameters are specified and, for functions, the result type or subtype is also specified.

RULES

The replacement elements for the PROC generic constraint are all procedures having the specified number of parameters of the specified types.

The replacement elements for the FUNC generic constraint are all functions having the specified number of parameters of the specified types and the specified result type.

The replacement elements for the TASK generic constraint are all tasks having the specified number of parameters of the specified types.

If a parameter subtype is specified, matching depends only upon the type to which it belongs. If the subtype parameter or result specified in the generic constraint does not match the actual subtype of the replacement element, the X_SUBTYPE exception is raised.

If the replacement element is itself overloaded or generic, then it is resolved in the calling scope and its needed items are bound there.

EXAMPLES

11.3.4  VALUE GENERIC CONSTRAINTS

10 - type   12 - subtype

A generic parameter with a value generic constraint has replacement elements which are manifest values.

RULES

A generic parameter with a value generic constraint must appear as an item in a formal translation time property list within the interface.

The only types and subtypes permitted are BOOL, INT, FLOAT, ENUM, and STRING types and subtypes.

For the STRING and ENUM constraints, uses of the formal generic parameter with the pattern declaration are type unresolved, if the replacement element is type unresolved. For the INT, FLOAT, ENUM[...], and STRING[t] constraints, uses of the formal generic parameter within the pattern declaration are subtype unresolved, if the replacement element is subtype unresolved.

EXAMPLES

11.4  NEEDS LIST

C - identifier   10 - type   12 - subtype   66 - formal trans time prop   81 - definable symbol

Whenever a generic parameter is a type, it is possible that the pattern declaration inside the generic declaration requires some procedures, functions or tasks that operate on variables or constants of that type. Such procedures, functions and tasks must be obtained from the scope in which the overloaded name is invoked, since nothing is known about the type ln the scope where the generic declaration appears. Such procedures, functions and tasks could be obtained by having additional generic parameters, but this would lead to a proliferation of such parameters. Instead, the needs list provides this mechanism. The definitions that appear in the needs list contain sufficient information to identify the needed procedure, function, or task uniquely, as well as completely specify its interface.

RULES

When a generically overloaded name is invoked, and the generic declaration includes a needs list, each definition in the needs list is resolved to the definition of the same name and matching interface known in the scope where the invocation appears.

If the needed definition is, itself, generically overloaded, then it is resolved and its needs list ls also resolved in that scope.

The needs list may not appear in any generic declaration whose pattern declaration is a type.

RED RATIONALE The NEEDS list constrains both the body of the generic, and the use of the generic. In the body of the generic, tasks and routines listed in the NEEDS list must be used as specified. In the use of the generic, there must be routines and tasks defined in the using environment as stated in the NEEDS list.

EXAMPLES