X3J3/97-104R2 Date: Feb 13, 1997 To: X3J3 From: /data Subject: Specs and syntax for R.5, PDTs This paper summarizes the specifications and syntax for parameterized derived types, item R.5 on the F2k requirements list of X3J3/97-010. Paper X3J3/96-141R1 was passed by X3J3 as the specifications for this requirement. That paper also had some illustrative syntax, which was not adopted at that time. Paper X3J3/96-176 was passed by X3J3 as the syntax for this requirement; it mostly just cited the illustrative syntax of the previous paper and made a few modifications. The current paper collects the previously passed specifications and syntax into a single document. There is almost no new material of substance (the one exception is explicitly noted below in section 2). It mostly consists of paper X3J3/96-141R1, modified in accordance with X3J3/96-176, and with some of the discussion of previous papers (notably WG5 D28 and X3J3/96-125) shortened or omitted. 1. Type-definition statement An optional list of type parameter names may be added in parens following the type-name in a type-definition statement. Example: TYPE matrix(kind, dim) 2. Type parameter typing All type parameters are of type integer. This may be confirmed by an explicit INTEGER declaration in the derived type definition. An explicit declaration can also be used to declare a type parameter to be of an integer kind other than default integer. Any explicit declarations of type parameters shall precede any component declarations for the derived type. PROPOSED SPECIFICATION CHANGE: Paper X3J3/96-176 also specified that any explicit type parameter declarations shall appear in the same order as the parameters listed on the TYPE statement. A straw vote on whether to retain that restriction was very indecisive (5 yes, 5 no, 7 undecided). In subsequent discussions, it was pointed out that this needlessly disallows some reasonable styles (such as declaring all of the kind parameters in one statement and all of the nonkind ones in another). It is now proposed to drop that restriction; its purpose was only to avoid potential user confusion about the correct order for writing the parameters in a constructor, but the current proposal for constructor syntax lessens the potential for confusion by separating the parameters from the components. Examples: TYPE matrix(kind, dim) !-- kind and dim are implicitly default integer REAL(kind) :: element(dim, dim) END TYPE TYPE humogous_matrix(kind, dim) INTEGER :: kind !-- Confirms kind as default integer INTEGER(selected_int_kind(12)) :: dim !-- Specify a non-default kind for dim REAL(kind) :: element(dim, dim) END TYPE 3. Kind vs nonkind parameters Type parameters are either kind type parameters or nonkind type parameters. Kind type parameters are modeled after the kind type parameters for the intrinsic types. Nonkind type parameters are modeled after the len type parameters for the intrinsic character type. Kind type parameters participate in overload resolution and may appear in initialization expressions (particularly, in kind expressions for components) and in specification expressions. Nonkind type parameters do not participate in overload resolution and may not appear in initialization expressions; they may appear in specification expressions. A kind type parameter is said to have the KIND attribute. Note that a type parameter may not be used as a (R405). A is defined to be either a digit string or a and it is not proposed to change this definition. Thus, it is not allowed to use forms like 123.4_wk, where wk is a type parameter. A type parameter may be declared to have the KIND attribute by using a KIND attribute on the INTEGER declaration of the parameter. It may also be declared to not have the KIND attribute by using a NONKIND attribute. If a type parameter does not explicitly or implicitly (see below) have the KIND attribute, then it has the NONKIND attribute by default; it is never required to explicitly specify the NONKIND attribute, but it is allowed as a confirmation. Example: TYPE stuff(p, dim) INTEGER, KIND :: p INTEGER, NONKIND :: dim REAL(selected_real_kind(p)) :: element(dim, dim) REAL(selected_real_kind(p+1)) :: scratch(2*dim) !-- p is used as a primary in initialization exprs. !-- dim is used as a primary in specification exprs. END TYPE 4. Implicit kind declaration With the exception mentioned below, appearance of a type parameter in a context requiring an initialization expression implicitly declares it to have the kind attribute. This implicit declaration may be confirmed by an explicit declaration. If a type parameter was declared with the NONKIND attribute, it is an error for it to appear in a context that requires an initialization expression. Example: TYPE matrix(kind, dim) REAL(kind) :: element(dim, dim) END TYPE !-- kind is implicitly a kind type parameter because !-- it appears in an initialization expr. !-- dim is implicitly nonkind. If a derived type MY_TYPE has a component COMP that is a pointer to a (possibly different) derived type, the appearance of a type parameter of MY_TYPE in the expressions for the kind type parameter values of COMP implicitly declares it to be a kind type parameter of MY_TYPE only if the type definition for COMP precedes that of MY_TYPE. For example TYPE type_1(a) INTEGER, KIND :: a !-- required because we don't yet know !-- whether type_2 has a kind type parameter. TYPE(type_2(a)), POINTER :: comp END TYPE TYPE type_2(b) !-- No explicit declaration of b needed here. TYPE(type_1(b)), POINTER :: comp END TYPE Note that this is never at issue except with pointer components because a non-pointer component is never allowed to be of subsequently defined type. 5. Object declaration. The syntax for declaring an object of parameterized derived type closely follows that of intrinsic parameterized types. The type parameter values are specified in parens after the type name, in either keyword or positional form. For positional form, the order corresponds to the parameter list of the type definition statement. There are no optional type parameters for derived types, so there is no concept of a default type-parameter value. The expression for a kind type parameter shall be an integer initialization expression. The expression for a nonkind type parameter may be either a specification expression or a "*". A "*" may be used only in the declaration of a dummy argument and indicates that the value is assumed from the corresponding actual argument. The expressions for type parameter values need not be of the same integer kind as the type parameter. Examples: TYPE(matrix(8,1000)) :: a TYPE(matrix(kind=8,dim=1000) :: b CALL sub(a, 300) SUBROUTINE sub(c, n) TYPE(matrix(kind=8, dim=*)) :: c !-- The dim value for matrix c is assumed from the !-- actual argument "a" and equals 1000 for the above call. INTEGER :: n TYPE(matrix(kind=8, dim=2*n)) :: d !-- The dim value for d is 600 for the above call. 6. Constructors The form of all derived type constructors (parameterized or not) is enhanced to allow a keyword form syntactically identical to that of a function call. However, we avoid for now the extra complications of actually defining these constructors to be functions. A constructor for a parameterized derived type has the same form as the constructor for the existing derived types with one addition. The constructor for a parameterized derived type has, in parens after the type name, specifications of the type parameter values, in either keyword or positional form. The syntax for the type and type parameters is then the same in a constructor as in an object declaration. Examples: TYPE stock_item !-- Note this is *not* a pdt. INTEGER :: id, holding, buy_level CHARACTER(len=20) :: desc REAL :: buy_price, sell_price END TYPE TYPE(stock_item) :: & s = stock_item(12345,75,10,"pencils", 1.5, 2.4) ... s = stock_item(desc="pencils", id=12345, & holding=75, sell_price=2.4, & buy_level=10, buy_price=1.5) TYPE node(key_len) !-- This one is a pdt CHARACTER(key_len) :: desc TYPE(node(keylen)), POINTER :: next END TYPE TYPE (node(16)) :: word ... word = node(16)("ralph", NULL()) 7. Type parameter inquiry Component selection syntax is used to inquire about type parameter values. An inquiry about a kind type parameter can appear as a primary in an initialization expression; an inquiry about a nonkind type parameter can appear as a primary in an initialization expression if the actual value inquired about was defined as a constant expression. An inquiry about any type parameter can appear as a primary in a specification expression. This directly follows the existing rules for how the existing intrinsic inquiry functions can be used. Examples: word%key_len !-- word declared as above. The component selection syntax is also extended to the intrinsic types. Examples: REAL(4) :: a CHARACTER*20 :: c WRITE (*,*) a%kind, c%len !-- i.e. 4 and 20 8. Intrinsic assignment Intrinsic assigment for parameterized derived types is defined only when the variable and expression have the same type and type parameter values 9. Argument association and overload rules The argument association rules follow those for objects of intrinsic types. The actual and dummy arguments must agree in type and type parameters. For nonkind parameters, the dummy argument may assume the value from the actual argument. Kind-type parameters may not be assumed. Kind type parameters may be used to resolve generic overloads. Example of generic overload resolved by kind type parameter: MODULE matrix_manipulation TYPE matrix(kind, dim) REAL(kind) :: element(dim, dim) END TYPE INTERFACE invert_in_place MODULE PROCEDURE invert_single, invert_double END INTERFACE CONTAINS SUBROUTINE invert_single(a) TYPE(matrix(kind=4, dim=*)), INTENT(INOUT) :: a ... END SUBROUTINE invert_single SUBROUTINE invert_double(a) TYPE(matrix(kind=8, dim=*)), INTENT(INOUT) :: a ... END SUBROUTINE invert_double END MODULE matrix_manipulation 10. Visibility and scoping The type parameter names are useable as keywords in object declarations even when the derived type has private components. Likewise, the parameter values can be inquired about even when the components of the derived type are private. Type parameter names are not subject to renaming; they never appear in contexts where their names might conflict or be ambiguous with other names except for component names of their corresponding derived type. It is not allowed for a component name to be the same as a type parameter name for the same derived type. Thus the type parameter names have more visibility than the component names. This is consistent with the usage with intrinsic types. 11. Sequence Parameterized derived types may have the SEQUENCE property. A parameterized derived type is never considered a numeric or character sequence type even if all of its ultimate components are numeric or character. Sequence parameterized derived types may appear in common and equivalence provided that all of the type parameter values are constants. This follows the existing rules for character.