J3/01-138 NUMBER: 000090 TITLE: What do ``Prior Specification'' and ``defined previously'' mean? KEYWORDS: initialization, prior specification, defined previously DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: What is a ``prior specification?'' The last normative paragraph of section 7.1.6.1 of the Fortran 95 standard, immediately before note 7.14 [94:38-41 in 97-007r2] states: ``If an initialization expression includes a reference to an inquiry function for a type parameter or an array bound of an object specified in the same , the type parameter or array bound shall be specified in a prior specification of the . The prior specification may be to the left of the inquiry function in the same statement.'' The first two sentences of the last normative paragraph of section 7.1.6.2 of the Fortran 95 standard, immediately before note 7.16 [96:32-35 in 97-007r2] are similar, but refer to specification expressions. Unfortunately, there is no definition of ``prior specification.'' Consider: 1. INTEGER :: P(complicated_expression_for_lower_bound_1: & & complicated_expression_for_upper_bound_1, & & complicated_expression_for_lower_bound_2: & & complicated_expression_for_upper_bound_2) = & & RESHAPE( (/ 11, 21, 12, 22 /), SHAPE(P) ) (Notice the reference to P in the .) Some processors reason ``the `specification' of P is only the specification of its name, kind, rank and array bounds, and therefore is `prior' by the time the is encountered,'' and accept this. Others reason ``the `specification' of P is the syntax term defined by syntax rule R504 on page 47, which includes the , and it is therefore not `prior' until the is completely specified,'' and do not accept this. By way of further examples, which of the following are standard conforming? 2. INTEGER(selected_int_kind(4)) :: A(KIND(A)) 3. INTEGER :: A(2,2*SIZE(A,1)+1) 4. CHARACTER :: C(10)*(SIZE(C,1)) 5. INTEGER :: P(10) = LBOUND(P,1) The paragraphs cited above are silent concerning inquiry functions that are not for type parameters or array bounds. These include BIT_SIZE, DIGITS, EPSILON, MAXEXPONENT, MINEXPONENT, PRECISION, RADIX, RANGE and TINY. The results of all of these are derived, however, from the types and kind type parameters of their arguments. Are the objects about which these functions inquire required to be specified in a prior specification of the , and is that specification allowed to be in the same statement so long as it is to the left of the inquiry function of which it is an argument? Which of the following are standard conforming? 6: INTEGER :: B = BIT_SIZE(B) 7. INTEGER :: B(BIT_SIZE(B)) 8. INTEGER :: D = DIGITS(D) 9. INTEGER :: D(DIGITS(D)) 10. REAL :: X = EPSILON(X) One could construct obvious similar examples for the remainder of inquiry functions that do not inquire about type parameters or array bounds. RELATED QUESTION The second normative paragraph in subclause 5.1.2.1 [52:27-28 in 97-007r2] states ``Any named constant that appears in the initialization expression shall have been defined previously in the same type declaration statement....'' The third normative paragraph after syntax rule R531 in subclause 5.2.9 [61:4-7 in 97-007r2] is similar. Does ``defined previously'' mean that all of the properties of the named constant shall have been defined previously, or that a referenced property of it shall have been defined previously? E.g. if the KIND is needed, is it necessary for the value to have been defined? ANSWER: The intention was to allow for all cases where an expression in an depends on an attribute that is defined ahead of the expression itself. All the above examples conform to the standard. Edits are provided to make this clear. The related text in 5.1.2.1 is not ambiguous. It says 'Any named constant ... shall have been defined previously ...' whereas the text in 7.1.6.1 refers to `a reference to an inquiry function for a type parameter or an array bound'. 5.1.2.1 requires that the named constant be completely defined. Similarly, the text in 5.2.9 is not ambiguous. We have taken the opportunity to correct the text in the first lines of the referenced paragraphs in 7.1.6.1 and 7.1.6.2. EDITS: Page 94, Subclause 7.1.6.1. In the first line of the last paragraph of page 94 [94:38], replace 'for a type parameter' by 'that depends on a type parameter'. Page 94, Subclause 7.1.6.1, add to the last line of page 94 [94:40-41] 'The prior specification may be to the left of the inquiry function in the same .' Page 96, Subclause 7.1.6.2. In the first line of the last paragraph of the subclause [96:32], replace 'for a type parameter' by 'that depends on a type parameter'. Page 96, Subclause 7.1.6.2, after the second sentence of the last paragraph of the subclause [96:34-35] add 'The prior specification may be to the left of the inquiry function in the same .' .................................................................... FIRST ALTERNATIVE ANSWER: The intention was to allow for the case where an object is given a value in a type declaration statement and there is a reference in the expression for the value to an attribute that is defined ahead of the expression itself. Examples 1, 5, 6, 8, and 10 above conform to the standard. It was also intended that an expression for an array bound or character length in an be permitted to depend on the type and kind type parameter of the object being declared. Examples 2, 7, and 9 above conform to the standard. It was not intended that an expression for an array bound or character length in an be permitted to depend on an array bound or the character length of the object being declared. Examples 3 and 4 above do not conform to the standard. Edits are provided to make this clear. The related text in 5.1.2.1 is not ambiguous. It says 'Any named constant ... shall have been defined previously ...' whereas the text in 7.1.6.1 refers to `a reference to an inquiry function for a type parameter or an array bound'. 5.1.2.1 requires that the named constant be completely defined. Similarly, the text in 5.2.9 is not ambiguous. We have taken the opportunity to correct the text in the first lines of the referenced paragraphs in 7.1.6.1 and 7.1.6.2. EDITS: Page 94, Subclause 7.1.6.1. In the first line of the last paragraph of page 94 [94:38], replace 'for a type parameter' by 'that depends on a type parameter'. Page 94, Subclause 7.1.6.1, replace the last sentence of page 94 [94:40-41] by 'The prior specification may be to the left of the inquiry function in the same statement, but an expression for an array bound or character length shall not reference an array bound or the character length of the object being declared.' Page 96, Subclause 7.1.6.2. In the first line of the last paragraph of the subclause [96:32], replace 'for a type parameter' by 'that depends on a type parameter'. Page 96, Subclause 7.1.6.2, replace the second sentence of the last paragraph of the subclause [96:34-35] by 'The prior specification may be to the left of the inquiry function in the same statement, but an expression for an array bound or character length shall not reference an array bound or the character length of the object being declared.' .................................................................... SECOND ALTERNATIVE ANSWER: The intention was to allow for the case where an object is given a value in a type declaration statement and there is a reference in the expression for the value to an attribute that is defined ahead of the expression itself. Examples 1, 5, 6, 8, and 10 above conform to the standard. It was not intended that an expression for an array bound or character length be permitted to reference an attribute of the object being declared. Examples 2, 3, 4, 7, and 9 above do not conform to the standard. Edits are provided to make this clear. The related text in 5.1.2.1 is not ambiguous. It says 'Any named constant ... shall have been defined previously ...' whereas the text in 7.1.6.1 refers to `a reference to an inquiry function for a type parameter or an array bound'. 5.1.2.1 requires that the named constant be completely defined. Similarly, the text in 5.2.9 is not ambiguous. We have taken the opportunity to correct the text in the first lines of the referenced paragraphs in 7.1.6.1 and 7.1.6.2. EDITS: Page 94, Subclause 7.1.6.1. In the first line of the last paragraph of page 94 [94:38], replace 'for a type parameter' by 'that depends on a type parameter'. Page 94, Subclause 7.1.6.1, replace the last sentence of page 94 [94:40-41] by 'The prior specification may be to the left of the inquiry function in the same statement, but an expression for an array bound or character length shall not reference an attribute of the object being declared.' Page 96, Subclause 7.1.6.2. In the first line of the last paragraph of the subclause [96:32], replace 'for a type parameter' by 'that depends on a type parameter'. Page 96, Subclause 7.1.6.2, replace the second sentence of the last paragraph of the subclause [96:34-35] by 'The prior specification may be to the left of the inquiry function in the same statement, but an expression for an array bound or character length shall not reference an attribute of the object being declared.' SUBMITTED BY: Van Snyder HISTORY: 00-229 m154 Submitted 00-324 m155 Amended