ISO/IEC JTC1/SC22/WG5 N1411 WG5 contribution on Interpretation Requests of Japan in WG5-N1393 (J3/00-006r1) Masayuki Takata NUMBER: JP-4 TITLE: Construction of derived-type values KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: JP-4) 4.4.4 Construction of derived-type values Before NOTE 4.34: "Where a component in the derived type is a pointer, the corresponding constructor expression shall evaluate to an object that would be an allowable target for such a pointer in a pointer assignment statement(7.5.2)." Change `an object' to `a result value'. A value of an expression can not be an object, by definition. ANSWER: Agreed. EDIT: [45:8] Replace "an object" by "a result value". SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 draft answer ---------------------------------------------------------------------- NUMBER: JP-5 TITLE: Construction of array values KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: JP-5) 4.5 Construction of array values, "The ac-do-variable of an ac-implied-do that is in another ac-implied-do shall not appear as the ac-do-variable of the containing ac-implied-do." This sentence should be a Constraint. ANSWER: Agreed. EDIT: [45:36+] Add: "Constraint: The ac-do-variable of an ac-implied-do that is in another ac-implied-do shall not appear as the ac-do-variable of the containing ac-implied-do." [46:3-5] Delete the sentence "The ac-do-variable ... ac-implied-do.". SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 draft answer ---------------------------------------------------------------------- NUMBER: JP-6 TITLE: Type declaration statements KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: JP-6) 5.1 Type declaration statements As for the 16th and 19th constraint after R506: the 16th: "Constraint: The function-name shall be the name of an external function, an intrinsic function, a function dummy procedure, or a statement function." Because the syntactic class `object-name' is only defined as a `name' in the standard, the following constraint should be added here: Constraint: The object-name shall be the name of a data object. After that, in the 19th: "Constraint: initialization shall not appear if object-name is dummy argument, a dummy argument, a function result, an object in a named common block unless the type declaration is in a block data program unit, an object in blank common, an allocatable array, an external name, an intrinsic name, or an automatic object." In the above, `a function result,' should be removed. If we can not add the constraint above, `a statement function' should be added in the 19th constraint. DISCUSSION: There is a typographical error in the quoted 19th constraint in the question in that "dummy argument" appears twice. ANSWER: Agreed. EDIT: [48:26+] Add: "Constraint: The object-name shall be the name of a data object." [48:31] Delete "a function result,". SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 draft answer ---------------------------------------------------------------------- NUMBER: JP-8 TITLE: Type declaration statements KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: JP-8) 5.1 Type declaration statements After NOTE 5.3: "If a length-selector (5.1.1.5) is a nonconstant expression, ..." Change `length-selector' to `char-selector', `char-len-selector' or `character-length'. ANSWER: Agreed, but with 'char-length' as the substitute text. EDIT: [49:5] Replace "length-selector" by "char-length". SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 draft answer ---------------------------------------------------------------------- NUMBER: JP-12 TITLE: Bounds of each dimension of an array pointer KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: JP-12) 5.1.2.4.3 (2) after R518 (Page 55 Line 41) states that: "(2) They are specified in a pointer assignment statement. ..." In this description, the term "pointer assignment statement" should be changed to "pointer assignment". Reason : The bounds of each dimension of an array pointer may be specified not only in a pointer assignment statement but also in a derived-type intrinsic assignment statement with a component of an array pointer. ANSWER: Agreed EDIT: [55:41] Delete "statement". SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 draft answer ---------------------------------------------------------------------- NUMBER: JP-16 TITLE: Multiple occurrence of namelist-group-name in NAMELIST statement KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: JP-16) 5.4 2nd paragraph after R545 and constraints (Page 66 Line 11) states that: "Any namelist-group-name may occur in more than one NAMELIST statement in a scoping unit." Can a namelist-group-name occur more than once in one NAMELIST statement ? Is the following NAMELIST statement standard conforming ? NAMELIST /NLIST/ A, B /NLIST/ C, D If this is standard conforming, is it the same as the following ? NAMELIST /NLIST/ A, B, C, D ANSWER: Yes, the rules should be analogous to those for named common blocks at [69:16-19]. EDIT: [66:11] Replace "in more than one" by "more than once in one or more" [66:11] Replace "statement" by "statements" SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 draft answer ---------------------------------------------------------------------- NUMBER: JP-17 TITLE: Multiple occurrence of namelist group object in namelist group KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: JP-17) 5.4 3rd paragraph after R545 and constraints states that: "A namelist group object may be a member of more than one namelist group." Can a namelist group object occur more than once in one namelist group? Is the following NAMELIST statement standard conforming? NAMELIST /NLIST/A,B,A ANSWER: No. EDIT: [66:14] Add new sentence at the end of the line: "A namelist group object shall not appear more than once in a single namelist group." SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 draft answer ---------------------------------------------------------------------- NUMBER: JP-24 TITLE: The bnf term shared-term-do-construct KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: JP-24) In 8.1.4.2, second constraint below R833 states that: "The do-term-shared-stmt shall be identified with a label and all of the label-do-stmts of the shared-term-do-construct shall refer to the same label." This implies a label-do-stmts of the outer-most outer-shared- do-construct will permit not to refer to the same label, because shared-term-do-construct does not include outer-most outer- shared-do-construct. So the term "shared-term-do-construct" should be changed to "inner-share-do-construct and outer-shared-do-construct." DISCUSSION: There is a typographical error in the question - "8.1.4.2" should read "8.1.4.1.2". The following amplification of the question was provided at the August 2000 WG5 meeting: The present BNF does not preclude the following as a single construct: do 10 i=1,5 ! outer do 20 j=1,5 ! outer do 20 k=1,5 ! outer do 20 l=1,5 ! inner ... 20 continue ! shared ANSWER: Agreed. There is a minor typo in the suggested replacement text. EDIT: [127:29.5] Replace "shared-term-do-construct" by "inner-shared-do-construct and outer-shared-do-construct". {The intention is to alter the second line of the second constraint following R833. The line numbering is awry in the F95 copy being used.} SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 draft answer ---------------------------------------------------------------------- NUMBER: JP-31 TITLE: Signs of literal constants KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: JP-31) The fourth sentence of 10.8 and sixth sentence of 10.9: "Each value is either a null value or one of the forms: c r*c r* where c is a literal constant or a nondelimited character constant and r is an unsigned, nonzero, integer literal constant." "a literal constant" should be "an optionally signed literal constant" ANSWER: Add the phrase, "if integer or real" to that last phrase above. EDIT: [175:5] Replace "constant or" by "constant, optionally signed if integer or real, or" [178:40] Replace "constant or" by "constant, optionally signed if integer or real, or" SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 draft answer ---------------------------------------------------------------------- NUMBER: JP-39 TITLE: Note 12.20 KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: JP-39) Page 204/ line 17 (NOTE 12.20): In 6.3.3.2, "If a pointer is currently associated with an allocatable array, the pointer shall not be deallocated". So "DEALLOCATE (B)" would NOT be permitted. DISCUSSION: This question was written on the mistaken reading that A was an allocatable array. The Japanese member body wishes to withdraw the interpretation request (WG5 meeting, August 2000). ANSWER: EDIT: SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation.