Ada '83 Language Reference Manual

Copyright 1980, 1982, 1983 owned by the United States Government. Direct reproduction and usage requests to the Ada Information Clearinghouse.

8.5. Renaming Declarations

A renaming declaration declares another name for an entity.

    renaming_declaration ::=
         identifier : type_mark   renames object_name;
       | identifier : exception   renames exception_name;
       | package identifier       renames package_name;
       | subprogram_specification renames subprogram_or_entry_name; 

The elaboration of a renaming declaration evaluates the name that follows the reserved word renames and thereby determines the entity denoted by this name (the renamed entity). At any point where a renaming declaration is visible, the identifier, or operator symbol of this declaration denotes the renamed entity.

The first form of renaming declaration is used for the renaming of objects. The renamed entity must be an object of the base type of the type mark. The properties of the renamed object are not affected by the renaming declaration. In particular, its value and whether or not it is a constant are unaffected; similarly, the constraints that apply to an object are not affected by renaming (any constraint implied by the type mark of the renaming declaration is ignored). The renaming declaration is legal only if exactly one object has this type and can be denoted by the object name.

The following restrictions apply to the renaming of a subcomponent that depends on discriminants of a variable. The renaming is not allowed if the subtype of the variable, as defined in a corresponding object declaration, component declaration, or component subtype indication, is an unconstrained type; or if the variable is a generic formal object (of mode in out). Similarly if the variable is a formal parameter, the renaming is not allowed if the type mark given in the parameter specification denotes an nconstrained type whose discriminants have default expressions.

The second form of renaming declaration is used for the renaming of exceptions; the third form, for the renaming of packages.

The last form of renaming declaration is used for the renaming of subprograms and entries. The renamed subprogram or entry and the subprogram specification given in the renaming declaration must have the same parameter and result type profile (see 6.6). The renaming declaration is legal only if exactly one visible subprogram or entry satisfies the above requirements and can be denoted by the given subprogram or entry name. In addition, parameter modes must be identical for formal parameters that are at the same parameter position.

The subtypes of the parameters and result (if any) of a renamed subprogram or entry are not affected by renaming. These subtypes are those given in the original subprogram declaration, generic instantiation, or entry declaration (not those of the renaming declaration); even for calls that use the new name. On the other hand, a renaming declaration can introduce parameter names and default expressions that differ from those of the renamed subprogram; named associations of calls with the new subprogram name must use the new parameter name; calls with the old subprogram name must use the old parameter names.

A procedure can only be renamed as a procedure. Either of a function or operator can be renamed as either of a function or operator; for renaming as an operator, the subprogram specification given in the renaming declaration is subject to the rules given in section 6.7 for operator declarations. Enumeration literals can be renamed as functions; similarly, attributes defined as functions (such as SUCC and PRED) can be renamed as functions. An entry can only be renamed as a procedure; the new name is only allowed to appear in contexts that allow a procedure name. An entry of a family can be renamed, but an entry family cannot be renamed as a whole.

Examples:

    declare
       L : PERSON renames LEFTMOST_PERSON; -- see 3.8.1
    begin
       L.AGE := L.AGE + 1;
    end; 

    FULL : exception renames TABLE_MANAGER.TABLE_FULL; -- see 7.5 

    package TM renames TABLE_MANAGER; 

    function REAL_PLUS(LEFT, RIGHT : REAL   ) return REAL    renames "+";
    function INT_PLUS (LEFT, RIGHT : INTEGER) return INTEGER renames "+"; 

    function ROUGE return COLOR renames RED;  --  see 3.5.1
    function ROT   return COLOR renames RED;
    function ROSSO return COLOR renames ROUGE; 

    function NEXT(X : COLOR) return COLOR renames COLOR'SUCC; -- see 3.5.5 

Example of a renaming declaration with new parameter names:

    function "*" (X,Y : VECTOR) return REAL renames DOT_PRODUCT; -- see 6.1 

Example of a renaming declaration with a new default expression:

    function MINIMUM(L : LINK := HEAD) return CELL renames MIN_CELL; -- see 6.1 

Notes:

Renaming may be used to resolve name conflicts and to act as a shorthand. Renaming with a different identifier or operator symbol does not hide the old name; the new name and the old name need not be visible at the same points. The attributes POS and VAL cannot be renamed since the corresponding specifications cannot be written; the same holds for the predefined multiplying operators with a universal_fixed result.

Calls with the new name of a renamed entry are procedure call statements and are not allowed at places where the syntax requires an entry call statement in conditional and timed entry calls; similarly, the COUNT attribute is not available for the new name.

A task object that is declared by an object declaration can be renamed as an object. However, a single task cannot be renamed since the corresponding task type is anonymous. For similar reasons, an object of an anonymous array type cannot be renamed. No syntactic form exists for renaming a generic unit.

A subtype can be used to achieve the effect of renaming a type (including a task type) as in

    subtype MODE is TEXT_IO.FILE_MODE;                                               

References: allow, attribute, base type, conditional entry call, constant, constrained subtype, constraint, declaration, default expression, depend on a discriminant, discriminant, elaboration, and 3.9, entry, entry call, entry call statement, entry declaration, entry family, enumeration literal, evaluation of a name, exception, formal parameter, function, identifier, legal, mode, name, object, object declaration, operator, operator declaration, operator symbol, package, parameter, parameter specification, procedure, procedure call statement, reserved word, subcomponent, subprogram, subprogram call, subprogram declaration, subprogram specification, subtype, task object, timed entry call, type, type mark, variable, visibility.

Rationale references: 11.3.4 Renaming

Style Guide references: 5.6.9 Blocks, 5.7.1 The Use Clause, 5.7.2 The Renames Clause

Address any questions or comments to adainfo@sw-eng.falls-church.va.us.