From adt10@amdahl.uts.amdahl.com Tue Mar 31 07:08:48 1992 Received: from mcsun.EU.net by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8) id AA25768; Tue, 31 Mar 92 07:08:48 +0200 Received: from CHARON.AMDAHL.COM by mcsun.EU.net with SMTP id AA06509 (5.65a/CWI-2.153); Tue, 31 Mar 1992 07:08:25 +0200 Received: from amdahl.uts.amdahl.com by charon.amdahl.com (4.0/SMI-4.1/DNS) id AA20854; Mon, 30 Mar 92 21:06:57 PST Received: by amdahl.uts.amdahl.com (/\../\ Smail3.1.14.4 #14.9) id ; Mon, 30 Mar 92 21:08 PST Message-Id: Date: Mon, 30 Mar 92 21:08 PST From: adt10@uts.amdahl.com (Andrew D. Tait) To: sc22wg5@dkuug.dk Subject: S20 X-Charset: ASCII X-Char-Esc: 29 Attached is the current draft of the S20, S20.120. There are a couple of errors where I could not figure things out. See Interpretations 000006 (where I could not read the response) and 000017 (where I have no idea what the question is!) The last line of this file contains the string: **************************** END OF S20.120 ****************************** Andrew ........................... START OF S20.120 ............................ INTERPRETATION NUMBER: 000001 REQUEST: 119-JCA-2 (119.002) QUESTION: In the following code fragments must the values of D be the same for all legal values of A, B, and C? TEMP=A+B D=C+TEMP and D=C+(A+B) ANSWER: No. Discussion: Section 6.6.4 of ANSI X3.9-1978 Programming Language FORTRAN states: Once interpretation has been established in accordance with these rules, the processor may evaluate any mathematically equivalent expression ... Therefore TEMP=A+B D=C+TEMP and D=C+(A+B) can result in different values of D because TEMP can be replaced with a mathematically equivalent expression. Section 10.1 requires that TEMP be evaluated, but it does not require that the value be used in subsequent invocations of TEMP. This situation is also described in Fortran 90 section 7.1.7.3. REFERENCES: 119-RL-1 (119.012) ISO/IEC 1539:1991 (E) section 7.1.7.3 ANSI X3.9-1978 section 6.6.4 ANSI X3.9-1978 section 10.1 -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000002 REQUEST: 117-ADT-5 (117.035) repeated as 118-ADT-3 (118.045) QUESTION: Some implementations of FORTRAN 77 supply a default PROGRAM program statement and program name when it is omitted from the main program. If the default program name conflicts with with a global name in the program is the processor standard conforming or not? For example: COMMON /MAIN/ A(1000) READ *,N CALL SUB(N) END SUBROUTINE SUB(N) COMMON /MAIN/ A(1000) DO 100 I=1,N A(I)=0.0 100 CONTINUE END If a processor supplies a PROGRAM statement with a default name MAIN, this will conflict with the common block name MAIN. Is such a processor standard conforming? If the processor supplied a name which could never conflict with a FORTRAN 77 name, would it be standard conforming? Would the processor in the example above be standard conforming if it used M_A_I_N, for example, instead of MAIN? ANSWER: This situation is covered by the third paragraph of of section 1.4 of ANSI X3.9-1978 Programming Language FORTRAN. Specifically, lines 25-27 state: A processor conforms to this standard if it executes standard-conforming programs in a manner that fulfills the interpretations prescribed herein. If, as in the example provided, the processor supplies a PROGRAM statement for a main program with a symbolic name which conflicts with another global name in the program, such that the program fails to execute then the processor does not conform to the standard. The processor may supply a default name which does not conflict with another global name and be standard conforming. Note that in Fortran 90 this situation is explicitly described in section C.11.1. REFERENCES: 119-ADT-1 (119.012), 119-RL-2 (119.048) ISO/IEC 1539:1991 (E) section C.11.1 ANSI X3.9-1978 section 1.4 (page 1-2, lines 25-27) -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000003 REQUEST: 118-ADT-2 (118.024) QUESTION: Is a processor which associates preconnected units with the files identified by the * in READ and WRITE statements standard conforming? ANSWER: No. Discussion: This situation is covered by section 12.9.2 of ANSI X3.9-1978 Programming Language FORTRAN. This section states that the asterisk identifies a particular processor-determined unit which is the same for a PRINT statement and a WRITE statement which contains an asterisk. The processor-determined unit is different for a READ statement which contains an asterisk. The specific answer to the question is "Yes". Note that in Fortran 90 this situation is explicitly described in section 9.3. REFERENCES: 119-ADT-2 (119.013) ISO/IEC 1539:1991 (E) section 9.3 ANSI X3.9-1978 section 12.9.2 -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000004 REQUEST: 119-JTM-2 (119.015) QUESTION: Is the following format specification valid in free format source? FORMAT(B N) ANSWER: Yes. Discussion: This situation is covered by section 10.1.1 which states that: Additional blank characters may appear at any point within the format specification, with no effect on the interpretation of the format specification, except within a character string edit descriptor... The appearance of this statement is intended to override all of the general rules related to the appearance of blanks. REFERENCES: 119-RPK-1 (119.056), & 119-JTM-2 (119.041) ISO/IEC 1539:1991 (E) sections 3.2, 3.3, 10.1.1, & 10.2.1 -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000005 REQUEST: 119-JTM-3 (119.016) QUESTION: Given the program: PROGRAM P CHARACTER*0 CH NAMELIST/OUT/CH OPEN(UNIT=8,DELIM='NONE') WRITE(UNIT=8,NML=OUT) END The namelist output record would be: &OUT CH= / Doesnot this conflict with the statement in section 10.9.2.2 that: A null value is not produced by namelist formatting. ANSWER: No. Discussion: Although the output produced by this program appears to contain a null value (to namelist input), actually a zero-length character string was written by the namelist output statement. Note that this is different from a null value (section 10.9.1.4) which has no meaning on output. The statement: A null value is not produced by namelist formatting. indicates that since all namelist group objects have a value, that value (in this case a zero-length string) is output. REFERENCES: 119-RPK-2 (119.064), & 119-JTM-6 (119.041) ISO/IEC 1539:1991 (E) sections 10.9.1.4, & 10.9.2.2, -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000006 REQUEST: 119-SML-1 (119.019) items 1 through 4 QUESTION: Which of the following procedure related specifications may jointly occur within a scoping unit? a. An interface body for the procedure and the appearance of the procedure name in a type statement b. An interface body for the procedure and the appearance of the procedure name in an EXTERNAL statement c. A module procedure definition and the appearance of the procedure name in a type statement d. A module procedure definition and an interface body for the procedure ANSWER: Only b. Discussion: Section 5.1 states the constraint: An entity must not be given explicitly any attribute more than once in a scoping unit. An interface body .....................? A module procedure definition similarly constitutes an explicit specification of its characteristics in the host scoping unit, so again its type must not be separately respecified in a type statement. In addition to the constraint in section 5.1, the case of the module procedure definition is also covered ??? statement in section 12.3.2.1 that An interface body in an interface block specifies an explicit interface for an existing external procedure or a dummy procedure, excluding module procedures, and by ?? statement later in 12.3.2.1 that A procedure must not have more than one explicit interface in a a given scoping unit. However, an interface body only implies that the procedure is external or dummy, so this may be confirmed by an EXTERNAL statement. This may be seen as analogous to the relation between DATA and SAVE. REFERENCES: 119-KWH-4A (119.071A) ISO/IEC 1539:1991 (E) sections 5.1, & 12.3.2.1 -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000007 REQUEST: 119-SML-1 (119.019) item 5, question 1 QUESTION: May a module procedure name be referred to on more than one MODULE PROCEDURE statement in a single generic interface block? ANSWER: The intent of the committee was to disallow the situation in this question. The standard might be read as though the following modification was made: Section 12.3.2.1 add a new constraint after other constraints: "Constraint: A can appear only once in a and can appear in only one ." REFERENCES: 120-MBSH-4A (120.096A) ISO/IEC 1539:1991 (E) section 12.3.2.1 -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000008 REQUEST: 119-SML-1 (119.019) item 5, question 4 QUESTION: May a module procedure name be referred to on more than one MODULE PROCEDURE statement in multiple interface blocks specifying the same generic name? ANSWER: Yes. Discussion: There is no restriction that forbids the situation in this question and therefore it is legal. Example: INTERFACE int_1 MODULE PROCEDURE foo, foo ! foo is illegal MODULE PROCEDURE foo1 MODULE PROCEDURE foo1 ! foo1 is illegal MODULE PROCEDURE foo2 END INTERFACE int_1 INTERFACE int_1 MODULE PROCEDURE foo2 ! legal END INTERFACE int_1 REFERENCES: 120-MBSH-4A (120.096A) -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000009 REQUEST: 120-LRR-4 (120.029), question 1 QUESTION: Are the generic interfaces of the same name accessible to the same program allowed? ANSWER: Yes. REFERENCES: 120-MBSH-1A (120.084A) ISO/IEC 1539:1991 (E) section 11.3.2 (paragraph 5 after last constraint). -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000010 REQUEST: 120-LRR-4 (120.029), question 2 QUESTION: Are two generic interfaces with the same name allowed in the same scoping unit? ANSWER: Yes. Discussion: Program example_1 interface int1 ... end interface ... interface int1 ... end interface Module mod1 interface int1 ... end interface ... end module mod1 module mod2 interface int1 ... end interface ... end module mod2 program example_1 use mod1, mod2 REFERENCES: 120-MBSH-1A (120.084A) -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000011 REQUEST: 120-LRR-4 (120.029), question 3 QUESTION: Did the standard intend to prohibit multiple accessible defined assignment interfaces? ANSWER: No. Discussion: The standard specifically includes "generic interfaces" of "the same name, the same operator, or are both assignments" in the rule of what will be interpreted as having a "single generic interface". The text cited on local entities was specifically discussing "names" and hence "generic names" were singled out. REFERENCES: 120-MBSH-1A (120.084A) ISO/IEC 1539:1991 (E) sections 11.3.2, 12.3.2.1, & 14.1.2 -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000012 REQUEST: 120-JTM-9 (120.046), question 3 QUESTION: Is the following code fragment valid Fortran 90? PARAMETER (A=1) IMPLICIT INTEGER (A) ANSWER: No. Discussion: In any scoping unit there is only one (possibly null) implicit typing map (5.3). Thus, in the statement (5.2.10), The named constant must have its type, shape, and any type parameters specified either by a previous occurrence in a type declaration statement in the same scoping unit, or by the implicit typing rules currently in effect for the scoping unit. the word "currently" is intended to mean that any IMPLICIT statement which would affect the named constant must occur previously in the scoping unit. REFERENCES: 120-LJM-5 (120-098) -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000013 REQUEST: 120-LRR-3 (120.028) QUESTION: Is the implicit environment of a module inherited by an interface block? ANSWER: The intent of the committee was that implicit mappings are not accessible in an interface body through host association. 1. In the example in section 5.3 for FUNCTION FUN in the interface block the comment should be changed FROM: ! All data entities must ! be declared explicitly TO ! All data entities need not ! be declared explicitly 2. In section 5.3 change "A program unit" in the last sentence of paragraph 3 (preceding: "IMPLICIT INTEGER (I-N)...") to "A scoping unit that is not host associated (12.1.2.2.1)" Discussion: MODULE Example IMPLICIT NONE INTERFACE FUNCTION FUN(I) ! All data entities need not INTEGER FUN, I ! be declared explicitly END FUNCTION FUN END INTERFACE ... END MODULE REFERENCES: 120-MBSH-2A (120.085A) ISO/IEC 1539:1991 (E) sections 2.2, 5.3, & 12.1.2.2.1 -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000014 REQUEST: 119-LRR-1, part II QUESTION: Given a definition of an external function such as the following where the function result is variable length, must the characteristics of the function be described by an interface block accessible to the calling procedure? FUNCTION f(i) INTEGER i,n CHARACTER*(n) f COMMON /b/ n ... END ANSWER: Yes. Discussion: Section 12.3.1.1 states: A procedure must have an explicit interface if ... (2) The procedure has ... (d) A result whose length type parameter value is neither assumed nor constant." That provision applies to this function. Section 12.3.1 indicates that an external procedure has an explicit interface only if an in interfce block is provided. REFERENCES: 119-KWH-3A (119-70A) ISO/IEC 1539:1991 (E) section 12.3.1 & 12.3.1.1 -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000015 REQUEST: 119-JTM-7 (119.042) part 1 QUESTION: Should the fourth constraint for R429 also apply to a in the ? ANSWER: Yes, the constraint should be: The character length specified by the in a or the in a (5.1, 5.1.1.5) must be a constant specification expression (7.1.6.2) Discussion: A non constant specification expression specifies an automatic character object that may be declared only in a procedure or procedure interface. It was never the intention to permit the specification of automatic objects in type definitions. The fifth constraint for R429 prohibits the only other automatic object, an automatic array. By extrapolation, it could be assumed that the length specified in a character would be similarly restricted. REFERENCES: 119-JTM-11 (119.054) ISO/IEC 1539:1991 (E) sections 4.4.1, 5.1, 5.1.1.5, & 7.1.6.2 -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000016 REQUEST: 119-JTM-7 (119.042) part 2 QUESTION: is there a similar interaction between a specified in both a and a as there is between a specified in both an and a ? ANSWER: Yes, the text following the constraints for R508 should be: The in a CHARACTER and the * in an or in a of a type definition specify character length. The * in an or specifies an individual length and overrides the length specified in the , if any. If a * is not specified in an or , the or specified in the is the character length. If the length is not specified in a or a * , the length is 1. Discussion: It was intended that character declarations in type definitions be symmetrical with character object declarations. REFERENCES: 119-JTM-12A (119.055A) ISO/IEC 1539:1991 (E) sections 4.4.1, 5.1, & 5.1.1.5 -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000017 REQUEST: 119-EAJ-1 (119.057) QUESTION: ? ANSWER: Multiple renames of the same do not constitute separate entities. Subsequent appearances of the refer to the single entity. For example: module UTIL procedure P public P end module UTIL module MID1 use UTIL, Q=>P !Q is merely a renaming of P public Q end module MID1 module MID2 use util, Q=>P !another renaming of the same entity P public Q end module MID2 subroutine ENDUSER use MID1 use MID2 call Q(...) !This is legal and refers to P end subroutine ENDUSER The portion of the standard in 11.3.2: Two or more accessible entities, other than generic interfaces, may have the same name only if no entity is referenced by this name in the scoping unit Use "referenced" in the ordinary English sense rather than its technical sense. That is, two or more accessible entities with the same name must not appear in the same scoping unit. So: use MID, AA=>BB use MID, AA=>CC is prohibited by the standard REFERENCES: 120-LF-1 (120.089) ISO/IEC 1539:1991 (E) section 11.3.2 -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000018 REQUEST: 120-JCA-13 (120.013) QUESTION: Line 3 of the first paragraph of 3.3.2.3 states: If character position 6 contains any character other than a blank or zero, character position 7-72 of this line constitute a continuation of the preceding non comment line. Can the character in character position 6 be a character outside the Fortran character set (for example, newline)? ANSWER: No. Throughout chapter 3 the term character is assumed to mean character in the Fortran character set. REFERENCES: 120-RL-1 (120.058) ISO/IEC 1539:1991 (E) sections 3.1 & 3.3.2.3 -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000019 REQUEST: 120-JCA-14 (120.014) QUESTION: Is the order of the coordinates correct in the last example of 4.5, considering the type definition of LINE in 4.4.1? ANSWER: Yes. Discussion: If the line is drawn between points X and Y where the coordinates of X are X1 and X2 and the coordinates of Y are Y1 and Y2. Admittedly, this is not the traditional naming scheme for the coordinates of two points that determine a line. Traditionally, a line would be drawn between points 1 and 2 where each point had an X and Y coordinate, but it is merely a matter of naming. Customary expectations would have been better satisfied if the first comment in the type definition of line in 4.4.1 were !X1, X2, Y1, Y2. In future revisions of the standard more care will be taken to create examples based on traditional naming schemes. REFERENCES: 120-JTM-10 (120.057) ISO/IEC 1539:1991 (E) sections 4.4.1 & 4.5 -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000020 REQUEST: 120-JCA-15 (120.015) & 120-JLS-5 (120.023) QUESTION: How does changing the name by which a derived type is referenced affect its use? For example, is the code below standard conforming and, if so, which specific procedure is invoked by the reference to GEN? module MOD type T1 sequence integer I,J end type T1 end module MOD use MOD, T2=>T1 type (T2) X interface GEN subroutine SPEC1(A1) type T1 sequence integer I,J end type T1 type (T1) A1 end subroutine SPEC1 subroutine SPEC2(A2) type T2 sequence integer I,J end type T2 type (T2) A2 end subroutine SPEC2 end interface GEN interface subroutine SPEC3(A3) use MOD type (T1) A3 end subroutine SPEC3 end interface ... call SPEC3(X) call GEN3(X) end ANSWER: Yes, the code is standard conforming. The reference to GEN should invoke the specific procedure SPEC1. Discussion: The rules governing this questions are stated in 4.4.2. Two alternatives are provide for entities to have the same type. The first alternative applies to the reference to SPEC3: Two data entities have the same type if they are declared with reference to the same derived-type definition. In this case, both the actual argument X and the dummy argument A3 are declared with reference to the type definition T1 in MOD. The second alternative applies to the analysis of the procedures in generic interface GEN: Data entities in different scoping units also have the same type if they are declared with reference to different derived-type definitions that have the same name, have the SEQUENCE property, and have structure components that do not have PRIVATE accessibility and agree in order, name, and attributes. The type definition in SPEC1 has the agreement with the type definition in MOD, so X and A1 have the same type. The definition in SPEC2 has a different name, so X and A2 have different types. Thus the reference to GEN invokes SPEC1. Note the fact that type T1 in MOD was accessible using a different name in the main program was irrelevant in both these analyses. REFERENCES: 120-KWH-1 (120.078) ISO/IEC 1539:1991 (E) section 4.4.2 -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000021 REQUEST: 120-JLS-1 (120.019) QUESTION: In the following example, to which type T1 does the FUNCTION statement refer? subroutine FRED type T1 real :: X,Y end type ... contains type (T1) function WILMA() type T1 integer I,J end type ... end function WILMA end subroutine FRED ANSWER: The question is moot, as such a program is not standard conforming. Discussion: 4.4.1 states the constraint: A derived-type must not be the same as the name of any intrinsic type nor the same as any other derived-type . Since the T1 defined in FRED is accessible in WILMA, a new T1 must not be defined in WILMA. Were the definition of T1 in FRED removed, the example still would not conform as it violates the requirement in 5.1.1.7: When a data entity is specified to be of derived type, the derived type must have been defined previously in the scoping unit or be accessible there by use or host association. Revising the internal procedure to read: function WILMA() type T1 integer I,J end type type (T1) WILMA ... end function WILMA would make the example syntactically conforming, but it would be effectively impossible to reference this function because type T1 would not be known outside WILMA. Were the SEQUENCE attribute added to the definition of T1 a reference to WILMA would then be possible. REFERENCES: 120-KWH-2A (120.083A) ISO/IEC 1539:1991 (E) sections 4.4.1 & 5.1.1.7 -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000022 REQUEST: 120-JLS-2 (120.020) cases 1 and 2 QUESTION: May a derived type contained in an internal procedure be the same as one contained in the host scoping unit? ANSWER: No. Discussion: This is prohibited by the last constraint following R424 in 4.4.1 which states that: A derived-type must not be the same as the name of any intrinsic type nor the same as any other derived-type . Note example 2 of C12.1 is illegal and should be corrected or noted as illegal. REFERENCES: 120-RPK-1A (120-092A) ISO/IEC 1539:1991 (E) sections 4.4.1 & C12.1 -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000023 REQUEST: 120-JLS-2 (120.020) case 3 QUESTION: Given that an implicit mapping is established for a letter in a host scoping unit. An internal procedure of that host scoping unit contains a PARAMETER statement which defines a named constant whose name begins with the letter in question. This is followed by an IMPLICIT statement which defines a different mapping for this letter. Is this legal? ANSWER: No. Discussion: 5.3 indicates that: In each scoping unit, there is a mapping, ... between each of the letters ... and a type... Hence within the internal procedure, the implicit mapping for X is to the type CHARACTER and the PARAMETER statement is illegal. REFERENCES: 120-RPK-2 (120-093) ISO/IEC 1539:1991 (E) section 5.3 -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000024 REQUEST: 120-JLS-2 (120.020) case 4 QUESTION: An internal procedure contains an IMPLICIT NONE statement and does not contain a type specification for the function result. Is this legal? ANSWER: No. Discussion: 12.5.2.2 states if the type of the function result is not explicitly specified: ... it is determined by the implicit typing rules in force within the function subprogram. As the null mapping has been specified for all letters within the internal function, the type of the result must be explicitly specified within the function. REFERENCES: 120-RPK-3A (120-094A) ISO/IEC 1539:1991 (E) section 12.5.2.2 -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000025 REQUEST: 120-JLS-2 (120.020) case 5 QUESTION: A host scoping unit contains two internal functions, F1 and F2. If F1 contains an IMPLICIT NONE and references F2, must F1 contain an explicit type declaration for F2? ANSWER: No. In fact if it did contain an explicit type specification for F2, F1 would be referencing an external function F2 and not the internal one contained in its host scoping unit. Discussion: 12.3.1 states: If a procedure is accessible in a scoping unit, its interface is either explicit or implicit in that scoping unit. The interface of an internal procedure ... is always explicit in such a scoping unit. Therefore, the interface of F2 is explicit in the host scoping unit. The function F2 is established to be specific in the host scoping unit by (2)(b) of 14.1.2.4 which states that a procedure name is specific: if that scoping unit contains a ... an internal procedure ... with that name; Furthermore, the function name F2 is established to be specific in the internal procedure F1 by (2)(f) of 14.1.2.4 which states: if that scoping unit contains no declarations of that name, that scoping unit is contained in the host scoping unit, and that name is established to be specific in the host scoping unit. As F2 is established to be specific within F1 by the above, 14.1.2.4.2 indicates that the F2 referenced by F1 is to the internal function F2 contained in the host scoping unit. Note that if F1 contains an explicit declaration for F2, by the rules of 14.1.2.4, F2 is not established to be either generic or specific in F1. Therefore, to resolve the procedure reference, the rules in 14.1.2.4.3 apply and the reference to F2 within F1 is to an external procedure with the name F2. REFERENCES: 120-RPK-1A (120-092A) ISO/IEC 1539:1991 (E) section 12.3.1, 14.1.2.4, 14.1.2.4.2 and 14.1.2.4.3 -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000026 REQUEST: 120-JLS-3 (120.021) QUESTION: Is it the intent of the standard is to state that the lower bound of an array expression is always 1, and the upper bound is equal to the number of elements in a given dimension, for all dimensions. Thus, given: REAL,TARGET,DIMENSION(5:10) :: A REAL,DIMENSION(:),POINTER :: P P => A(5:10) PRINT *, LBOUND (P) the print statement results in the value 1 being written. Previous versions of the draft state lower bounds of array expressions were 1; Where are those words in the current draft? Reading chapter 7 indicates that an expression may be a simply a primary, and a primary may be an array variable. Question 1: Does this mean, given the above declarations that P => A PRINT *, LBOUND (P) would also result in the value 1 being written (since A is an array expression), or should this print the value 5? Question 2: Is the intent of the standard that given an array with a declared lower bound other than one, the following relational expressions are false? REAL,TARGET,DIMENSION(5:10) :: A REAL,DIMENSION(:),POINTER :: P1, P2 INTERFACE SUBROUTINE FRED (X, Y) REAL,INTENT (IN),DIMENSION(:) :: X, Y END SUBROUTINE END INTERFACE P1 => A P2 => A(:) PRINT *, LBOUND (A) .EQ. LBOUND (A(:)) PRINT *, LBOUND (P1).EQ. LBOUND (P2) CALL FRED (A, A(:)) END SUBROUTINE FRED (X, Y) REAL,INTENT(IN),DIMENSION(:) :: X, Y PRINT *, LBOUND (X) .EQ. LBOUND (Y) END SUBROUTINE Question 3: If the above three print statements result in the values .FALSE., in what cases does the appearance of an array name constitute an array (carrying with it its dimension attributes), and in what cases does it constitute an expression (implying the lower bound is one)? That is, in cases where bounds information may be transmitted (pointer assignment and actual argument association at subprogram calls), does the appearance of an array or pointer name *without* a subscript following cause the bounds of the array or pointer to be transmitted, and does the appearance of the same array or pointer name followed by a subscript triplet with no lower or upper bound or stride (i.e. (:,:)) constitute an expression with a lower bound of one transmitted? In summary: (a) What are the bounds of an array pointer which has been pointer assigned to an array section? (b) What are the bounds of an array pointer which has been pointer assigned to a whole array? (c) What are the bounds of an assumed shape array? (d) What are the bounds of a pointer dummy argument? ANSWER: The output of the three example programs would be: 1) 1 2) 5 3) .FALSE. .FALSE. .TRUE. (a) Each lower bound is 1, and each upper bound is the size of the corresponding dimension of the array section. (b) The declared bounds of the whole array. (c) Each lower bound is the declared lower bound of the assumed shape array, or, if omitted, 1, and each upper bound is the size of the corresponding dimension of the array section plus the lower bound minus one. (d) The bounds of the target associated with the pointer actual argument. Discussion: Cases (a) and (b) are determined from the statements (5.1.2.4.3), ...The lower bound of each dimension is the result of the LBOUND function (13.13.52) applied to the corresponding dimension of the target. The upper bound of each dimension is the result of the UBOUND function (13.13.111) applied to the corresponding dimension of the target. Case (d) is determined from these statements in conjunction with the statement, "If the actual argument is currently associated, the dummy argument becomes associated with the same target" (12.4.1.1). Case (c) is described in section 5.1.2.4.2. REFERENCES: 120-LJM-4A (120.088A) ISO/IEC 1539:1991 (E) sections 5.1.2.4.2, 5.1.2.4.3, 12.4.1.1, 13.13.52, & 13.13.111 -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000027 REQUEST: 120-JLS-4 (120.022) QUESTION: If PTR has the POINTER attribute and TGT has the TARGET or POINTER attribute, under which of the following other conditions are PTR and TGT considered to be pointer associated, i.e., under which of the following conditions does ASSOCIATED(PTR,TGT) return .TRUE.: a) PTR and TGT have different types? b) PTR and TGT have different type parameters? c) PTR and TGT have different ranks? d) PTR and TGT have different sizes? e) PTR and TGT have different shapes? f) PTR and TGT have different bounds? g) PTR and TGT refer to the same set of array elements/storage units, but not in the same array element order? h) PTR and TGT have array elements/storage units whose range of memory addresses overlap, but they have no identical array elements/storage units? i) PTR and TGT have at least one but not all identical array elements/storage units and all the identical elements have the same subscript order value in both PTR and TGT? j) PTR and TGT have at least one but not all identical array elements/storage units but not all the identical elements have the same subscript order value in both PTR and TGT? ANSWER: If any of the above conditions are true, PTR and TGT are not pointer associated. Discussion: There are only three means by which a pointer may become pointer associated: via the ALLOCATE statement (6.3.1), via pointer assignment (7.5.2), or via argument association (12.4.1.1). In an ALLOCATE statement, the object created inherits its type, type parameters, rank, shape, size and bounds from those declared for, or specified with, the pointer name. In a pointer assignment, the type, type parameters, and rank of the pointer and target must conform, and the shape, size, and bounds (5.1.2.4.3) of the target determine those of the pointer. When a pointer actual argument is passed to a pointer dummy argument, the pointer dummy argument becomes pointer associated with the same target as the pointer actual argument. In all three of these cases, array elements of the pointer and the target correspond with one another in array element or der. Thus, since there is no other way for two objects to become pointer associated, all these properties must be the same. Note that other forms of association (name association and storage association) are distinct from, and orthogonal to, pointer association (14.6). REFERENCES: 120-LJM-3A (120.081A) ISO/IEC 1539:1991 (E) 5.1.2.4.3, 6.3.1, 7.5.2, 12.4.1.1, & 14.6 -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000028 REQUEST: 120-JLS-6 (120.024) QUESTION: is an implicitly typed entity with the same name as a host or use associated entity a reference to a local entity or the host or use associated entity? ANSWER: It is a reference to the host or use associated entity. 5.3, fourth paragraph (after IMPLICIT INTEGER (I-N), REAL (A-H,O-Z)) states that use or host association takes precedence over implicit typing. REFERENCES: 120-RL-3 (120.060) ISO/IEC 1539:1991 (E) section 5.3 -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000029 REQUEST: 120-JLS-7 (120.025) QUESTION: Is a defined operator name a generic identifier? Thus, is it illegal for a defined operator name to be the same as another class 1 entity within the same scoping unit (As defined in 14.1.2)? ANSWER: Yes. 12.3.2.1 states: The generic name, defined operator, or ... in a generic specification a generic identifier... therefore 14.1.2 applies and it is illegal for a defined operator name to be the same as another class 1 entity within the same scoping unit. REFERENCES: 120-RL-2A (120.059A) ISO/IEC 1539:1991 (E) sections 12.3.2.1 & 14.1.2 -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000030 REQUEST: 120-LRR-1 (120.026) QUESTION: Consider the following example: CHARACTER :: names(3)*20 names = (/'tom','dick','harry'/) This is believed to be illegal. From section 4.5, "Construction of array values": Constraint: Each expression in the must have the same type and type parameters. The length of the string is a type parameter. Thus the array constructor sample above is illegal because the strings have different lengths. Consider another example: CALL sub (/'tom','dick','harry'/) ... SUBROUTINE sub(names) CHARACTER :: names(:)*(*) WRITE(*,*) LEN(names) ... This also looks illegal. 1. Must each character string literal constant in an array constructor be the same length? 2. If the answer to 1 is "No", what values are printed by the second example? ANSWER: Each character literal constant in an array constructor must be the same length. Both examples are non-standard conforming. Discussion: The reasoning is correct. The length of a character constant is a type parameter. Therefore, by the cited constraint, all character literal constants in an array constructor must have the same length. This awkwardness was noted by X3J3, but the committee could not reach agreement on an acceptable way to allow character literal constants of differing lengths in an array constructor. REFERENCES: 120-LJO-1 (120.074) ISO/IEC 1539:1991 (E) section 4.5 -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000031 REQUEST: 120-LRR-2 (120.027) QUESTION: Section 14.1.3 states: The name of the variable that appears as the DO variable of an implied-DO in a DATA statement or an array constructor has a scope of the implied-DO list. It has the type and type parameter that it would have if it were the name of a variable in the scoping unit that contains the DATA statement or array constructor and this type must be integer. Is the following in error since c has type character and therefore does not have type integer: CHARACTER c INTEGER a(10) DATA (a(c), c=1,10)/10*5/ Is the following valid because, although c is a named constant, it has type integer: INTEGER c PARAMETER (c=5) INTEGER a(10) DATA (a(c), c=1,10)/10*5/ Is the following valid: TYPE(itype) CHARACTER field1 INTEGER field2 END TYPE INTEGER a(10) DATA (a(itype), itype=1,10)/10*5/ If itype were a variable it would have type integer and this would be valid. Does the fact that it is the name of a derived type cause a conflict? The second sentence cited above appears to allow: EXTERNAL j INTEGER a(10) DATA (a(itype), itype=1,10)/10*5/ The EXTERNAL statement declares j to be a global name. Since j is a subroutine it has no type, so the presence of the EXTERNAL statement is irrelevant. If j were a function, then it must be type integer for the presence of j in the DATA statement to be valid. Question 1: Is the Fortran 90 standard intentionally extending the FORTRAN 77 standard with respect to implied-DO variables in DATA statements? Did the Fortran 90 standard intentionally delete the material about common block names citeed above? Question 2: Are the conclusions and interpretations above correct or incorrect? If incorrect, for what specific reasons are they incorrect? Question 3: Are the example above standard conforming program fragments? If not, what are the specific reasons? Question 4: Are the rules for implied-DO variables in DATA statements and array constructors exactly the same? If they are not exactly the same, provide examples which illustrate the differences. ANSWER: The first example is in error because c is of type character and R537 requires integer type. The second example is in error. c is of type integer as required by R537 because its type is determined by treating it as if it were a variable in the scoping unit that includes the DATA statement (14.1.3). If c is "treated as a variable" in this context it will have type integer as required but it will also cease to be a variable since c is a named constant in the outer scope. The third example is in error. itype cannot be "treated as a variable" in the context outside the DATA statement because to do so would introduce two local entities in the same class and this is prohibited by 14.1.2. The fourth example is also in error. j cannot be "treated as a variable" in the context outside the DATA statement because to do so would introduce a variable with an external attribute which is prohibited by 5.1. With regard to the specific questions: 1. The Fortran 90 standard intentionally extended the FORTRAN 77 standard with respect to implied-DO variables in DATA statements in only one area: the variable in the outer scope can be an integer array name in Fortran 90 because arrays are also in Fortran 90, unlike FORTRAN 77. It is thought that the material about common block names was intentionally omitted from Fortran 90 because it was redundant. The nature of scoping is such that the implied-DO variable which has a scope of the statement cannot affect interpretation of any object in the surrounding scope with the same name. 2. The detailing of the conclusions and justifications for the examples answer this. 3. The detailing of the conclusions and justifications for the examples answer this. 4. The committee believes that the rules for implied-DO variables in DATA statements and array constructors, with respect to typing and scope are exactly the same. REFERENCES: 120-RRR-1A (120.069A) ISO/IEC 1539:1991 (E) sections 5.1, 5.2.9, 14.1.2, & 14.1.3 -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000032 REQUEST: 120-LRR-5 (120.030) QUESTION: Is the following program standard conforming? IMPLICIT TYPE(t1) (A-D) ! Note IMPLICIT range is A-D. TYPE (t1) SEQUENCE CHARACTER*10 name INTEGER emp_number END TYPE t1 a1%name='Fred' ! a1 is implicitly declared to be ! of type t1. ... CONTAINS SUBROUTINE inner IMPLICIT TYPE(t1) (D) ! D now overrides IMPLICIT for D ! in host. TYPE t1 INTEGER width INTEGER height END TYPE t1 d%width ! No problem here, d is implicitly ! declared with the t1 that is ! defined in inner. CALL outside(c) ! Is this an error? ... Is a reference to a1 (declared in the host) from inside inner permitted in this example? ANSWER: No, the example is not standard conforming. The fifth constraint to R424 clearly states that A derived must not be the same as the name of any intrinsic type nor the same as any other accessible derived type . The derived type definition for t1 in inner is illegal because of this constraint. Since the program is non standard conforming the second question is moot. However, if the first eight lines of the subroutine inner were replaced by the following: SUBROUTINE inner INTEGER t1 then this would have the effect of making the type t1 in the host inaccessible, which was the situation envisaged in the question. 4.4.1 states that If a derived type definition is private, then the type name, the structure value constructor (4.4.4) for the type, any entity that is of the type, and any procedure that has a dummy argument or function result that is of the type are accessible only within the module containing the definition. Although not explicitly stated within the standard, it is intended that the same rule should apply to a derived type definition that is inaccessible for any other reason. Since the derived type t1 is inaccessible in the subroutine inner in the modified example above, the rule implies that any objects of type t1 are also inaccessible in the subroutine inner. Therefore, a reference to a1 is not permitted from inside inner REFERENCES: 120-TMRE-2 (120.075) ISO/IEC 1539:1991 (E) section 4.4.1 -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000033 REQUEST: 120-LRR-6 (120.031) Part 1 QUESTION: In the following program, even though both interface blocks have the same name and thus might be considered to be merged into a single generic interface block, is function f1 (from module mod_1) accessible to the program but function f2 (from module mod_2) hidden? MODULE mod_1 PUBLIC int_1 INTERFACE int_1 ! Generic interface - PUBLIC. INTEGER FUNCTION f1(k) INTEGER k END FUNCTION END INTERFACE int_1 ... END MODULE mod_1 MODULE mod_2 PRIVATE int_1 INTERFACE int_1 ! Generic interface, same name - PRIVATE INTEGER FUNCTION f2(l) LOGICAL l END FUNCTION END INTERFACE ... END MODULE mod_2 PROGRAM example_1 USE mod_1, mod_2 ! Program accesses both modules. ... END ANSWER: No. Discussion: Because the name int_1 is private in the module mod_2, the interface for the function f2 is accessible in the program example_1, but NOT the generic name int_1. Therefore, the two interface blocks are NOT merged into a single generic interface block. The function f1 is, therefore, accessible in the program example_1 by either its specific name f1 or the generic name int_1; the function f2, on the other hand is accessible only by its specific name f2. REFERENCES: 120-TMRE-3 (120.076) -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000034 REQUEST: 120-LRR-6 (120.031) Part 2 QUESTION: If the following module is added to the example given in interpretation 000033, and the USE statement in the main program is changed to "USE mod_1, mod_2, mod_3", is the resulting program standard conforming? MODULE mod_3 PUBLIC int_1 INTERFACE int_1 ! Generic interface, same name - PUBLIC. INTEGER FUNCTION f3(l) LOGICAL l END FUNCTION END INTERFACE ... END MODULE mod_3 ANSWER: Yes, but not for the reason implied by the question. Discussion: The answer in interpretation 000033 shows that the function F2 (from module mod_2) does not share the same generic name, int_1, as the function f1 (from module mod_1). The new module mod_3 defines a new interface block int_1, which will be combined with the identically named interface block from module mod_1. In the program example_1 the generic name int_1 has the two specific names f1 and F3. However, since f2 is not part of the combined generic interface block the fact that f2 and f3 have the same dummy argument and result characteristics is of no significance, and the program is standard conforming. REFERENCES: 120-TMRE-3 (120.076) -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000035 REQUEST: 120-LRR-6 (120.031) Part 3 QUESTION: If the program and modules shown in interpretation 000033 are altered so that module mod_2 USEs mod_1 and the program example_1 only USEs mod_2 directly, is this an example of a standard conforming program? If it is standard conforming, does the program have access to function f1 but not f2? ANSWER: Yes, the program is standard conforming. Discussion: Within module mod_2 the two generic interface blocks are combined into a single interface block. However, since int_1 is declared to be private within module mod_2 only the specific names of the functions f1 and f2 are accessible to program units using mod_2 (c.f. interpretation 000033). Therefore, both the function f1 and f2 are accessible within the program example_1, but only by their specific names. REFERENCES: 120-TMRE-3 (120.076) -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000036 REQUEST: 120-LRR-7 (120.032) QUESTION: Is a pointer assignment statement of the form: PTR => A where A is an assumed-size array, standard conforming? ANSWER: No. This is prohibited by section 6.2.1, second paragraph, second sentence. REFERENCES: 120-RRR-2A (120.087A) ISO/IEC 1539:1991 (E) section 6.2.1 -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000037 REQUEST: 120-LRR-7 (120.032) QUESTION: If A is an assumed-size array: Is "PTR => A(:N)" standard conforming? Are "PTR => A(:)" and "PTR => A(N:)" standard conforming? ANSWER: "PTR => A(:N)" is standard conforming because A(:N) is a valid array section. Forms "PTR => A(:)" and "PTR => A(N:)" are not standard conforming because the array sections are prohibited by the second constraint after R621. REFERENCES: 120-RRR-2A (120.087A) ISO/IEC 1539:1991 (E) section 6.2.2 -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000038 REQUEST: 120-LRR-8 (120.033) Part 1, question 1 QUESTION: Is the form of the following example standard conforming? That is, can the same interface body exist in multiple generic interface blocks that are all accessible from a single scoping unit. MODULE mod_1 INTERFACE red SUBROUTINE cmn(k) INTEGER k END SUBROUTINE SUBROUTINE s(x) REAL x END SUBROUTINE END INTERFACE END MODULE MODULE mod_2 INTERFACE blue SUBROUTINE ss(y) REAL y END SUBROUTINE SUBROUTINE cmn(k) INTEGER k END SUBROUTINE END INTERFACE END MODULE PROGRAM example_1 USE mod_1, mod_2 INTEGER m ... CALL red(m) ... CALL blue(m) ... END PROGRAM ANSWER: No. The example is not standard conforming. Discussion: The last sentence of the second paragraph of 12.3.2.1 states A procedure must not have more than one explicit specific interface in a given scoping unit. In the example the subroutine cmn has two specific interfaces, one from each module in the program example_1 which is forbidden. The program could be mad standard conforming by making the name cmn private in one or both modules. REFERENCES: 120-TMRE-4 (120.077) ISO/IEC 1539:1991 (E) section 12.3.2.1 -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000039 REQUEST: 120-LRR-8 (120.033) Part 1, question 2 QUESTION: If the answer in interpretation 000038 is yes, may the program unit also reference the procedure, cmn, by its specific name? ANSWER: As indicated in interpretation 00038, the example is only standard conforming if the subroutine cmn is private in one or both modules. If it it is private in one module and public in the other then it may be accessed by its specific name in the usual way since the other occurrence of the same name is not accessible. REFERENCES: 120-TMRE-4 (120.077) -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000040 REQUEST: 120-LRR-8 (120.033) Part 2 QUESTION: If the names are removed from the interface blocks in both modules in interpretation 000038, thus making them non-generic, and the subroutine calls in program example_1 replaced by "CALL cmn(m)", is the resulting program standard conforming? That is, may a procedure interface description occur in multiple non generic interface blocks that are accessible to a given scoping unit and may the program unit reference the procedure? ANSWER: No. Discussion: The last sentence of the second paragraph of 12.3.2.1 states A procedure must not have more than one explicit specific interface in a given scoping unit. REFERENCES: 120-TMRE-4 (120.077) ISO/IEC 1539:1991 (E) section 12.3.2.1 -------------------------------------------------------------------------- INTERPRETATION NUMBER: 000041 REQUEST: 120-LRR-9 (120.034) QUESTION: When a pointer is passed as an actual argument, is the intent of the standard as follows: Dereferencing of the pointer is dependent on the interface of the called procedure. That is, if the dummy argument is known to be a pointer (with matching type, ext.) then the pointer actual argument is NOT dereferenced - the pointer itself is passed. Conversely, if the dummy argument is unknown or is known to not be a pointer then the pointer dummy argument is dereferenced so that its target is passed (possibly through a temporary)? If yes, please quote the text that specifies the meaning of passing a pointer as an actual argument. ANSWER: Section 5.1.2.4.3 indicates that a pointer actual argument may be associated with either a pointer dummy argument or a non-pointer dummy argument. The semantics of a pointer actual argument associated with a pointer dummy argument are specified in section 12.4.1.1. When a pointer actual argument is associated with a non-pointer dummy argument, the actual arguments associated target object becomes associated with the dummy argument. Section 7.1.4.1 states If a pointer appears as a primary in an intrinsic operation or a defined operation in which it corresponds to a non-pointer dummy argument, the associated target object is referenced. Discussion: The standard does not specify implementation details. A valid implementation would allow passing a descriptor when a pointer actual argument is associated with a pointer dummy argument and a temporary when the dummy argument is a non-pointer. Another valid implementation would be to pass a descriptor in both cases. Since the notion of referencing and dereferencing pointers is implementation dependent, the standard does not use these terms when discussing pointers and targets. The standard does state when a pointer's association status may change (pointer assignment allocation, deallocation, nullification, and association with a dummy argument which is a pointer) and several cases where a pointer name refers to the associated target object (assignment as primary in an expression, and an I/O list). There is also an example of a pointer actual argument associated with a non-pointer dummy argument in section 12.5.2.9. Future revisions of the standard should explicitly state the semantics of associating pointer actual arguments with non-pointer dummy arguments in the section which describes arguments associated with dummy objects (12.4.1.1). This section should also state pointer actual arguments may be associated with pointer or non-pointer dummy arguments, and additional examples should be added for clarity. REFERENCES: 120-JLS-9 (120.079) ISO/IEC 1539:1991 (E) sections 5.1.2.4.3, 7.1.41, 7.5.1.5, 9.4.4.4, 12.4.1.1, 12.5.2.9 -------------------------------------------------------------------------- **************************** END OF S20.120 ******************************