J3/16-271r1 To: J3 From: Van Snyder & Malcolm Cohen Subject: Comments on Clause 15 Date: 2016 October 11 1a. Edits accepted with modification [302:22+] 15.4.3.2 Interface block, R1506 Insert paragraph break between R1506 and R1507 . {Inappropriately close.} [302:34-39] Same subclause, C1502, Replace "... . If" with ", the shall specify exactly the same , except if", making the whole constraint read: "C1502 (R1501) If the includes a , the shall specify exactly the same , except if one is .LT., .LE., .GT., .GE., .EQ., or .NE., the other is permitted to be the corresponding operator <, <=, >, >=, ==, or /=." {Simplify this grotesquely long constraint.} [311:16,30,31] 15.4.3.7 Procedure declaration statement, C1527 and p5, "with a NAME=" -> "with NAME=", "with NAME=" hyperlink NAME=, "without a NAME=" -> "without NAME=", hyperlinked. {Improve wording and hyperlinking.} [321:1-2] 15.5.2.7 Pointer dummy variables, p5, Delete whole paragraph "If... alloctable... allocated.". {This is already required by p2 which says that it must be a valid target in a pointer assignment statement, and this applies whether optional or not, so duplicitous as well as duplicative.} 1b. Edits rejected [299:20+ 15.2.2.2p0+] Would be easier to understand if p4 were first. Move [299:28-29 15.2.2.2p4] to [299+20+] REJECTED: p4 first is not actually easier to understand. [303:5-6 C1505] C1505 does not specify the same requirements as 15.7. Replace C1505: "C1505 (R1505) An for a pure procedure shall specify an interface that meets the requirements of 15.7." REJECTED: This would be a TECHNICAL CHANGE, for which there is insufficient motivation at this time. [313:6 C1530] C1530 cannot constrain a in a to designate a function. All it can do is constrain against it designating a subroutine. Replace C1530: "C1530 (R1521) The shall not designate a procedure known to be a subroutine." [131:9 C1532] C1530 cannot constrain a in a to designate a subroutine. All it can do is constrain against it designating a function. Replace C1532: "C1532 (R1522) The shall not designate a procedure known to be a function." [313:16+ C1536+] To replace the requirement lost by revising C1530 and C1532, replace their original text here as ordinary normative text (not constraints) in a new paragraph: "The in a shall designate a function. The in a shall designate a subroutine." REJECTED: These appear to be philosophically defensible as is. Further consideration on other approaches can be pursed at a different time. [314:1 C1540] Delete "used as" or replace "be used" with "appear". REJECTED: This is already correct Fortran terminology. [317:14-15 15.5.2.4p4] Replace the comma after kind with "and". After "dummy argument" insert "is not assumed, ". REJECTED: This is unnecessary. [322:7,14 15.5.2.9p2,3] Insert "effective" after "corresponding" twice. REJECTED: "corresponding actual argument" is already correct. [322:7-8 15.5.2.9p2] After "shall be a function" replace the comma with "or". Delete ", or dummy procedure" {simplification possible because of the insertion of "effective" above}. REJECTED: Does not work. [322:14 15.5.2.9p3] After "shall be a subroutine" replace the comma with "or". Delete ", or dummy procedure" {simplification possible because of the insertion of "effective" above}. REJECTED: Does not work. [322:29-30 15.5.2.11p1] Delete ", a default character scalar,". Replace "with the C" with "with default or C" {simplification}. REJECTED: Not a significant enough improvement. [322:34 15.5.2.11p2] Delete "default character or". Replace "with the C" with "with default or C" {simplification}. REJECTED: Not a significant enough improvement. [322:39 15.5.2.11p3] Delete "default character or". Replace "with the C" with "with default or C" {simplification}. REJECTED: Not a significant enough improvement. [325 NOTE 15.37] Normative text appears in both paragraphs. Editor's choice how to reword it. REJECTED: Actually the text is not normative but informative, and contains requirements. Requirements are not allowed by ISO to be informative. [325 NOTE 15.38] Replace "This restriction" with "The restriction described in NOTE 15.37" (or combine the two notes). REJECTED: Both deferred to another paper. [328:6 15.5.5.3p1] Append "then" after the comma {If A then if B... reads better than If A if B...}. REJECTED: Unnecessary. This is not a sentence, but a list with an introductory condition. [331:3-4 C1564] C1564 is entirely subsumed by C1562. Delete C1564. REJECTED: These are in fact almost entirely disjoint, they just look superficially to be the same. [330:34-331:6 R1531,C1561-C1563,C1565] R1531, C1561-C1563, and C1565 would be clearer if they appeared after R1533. Move them to [331:10+ R1533+] REJECTED: This has already been formatted by another paper. [335:21 C1581] Insert "function" after "intrinsic". REJECTED: Unnecessary wordsmithing of obsolete feature. [337:end-2 NOTE 15.52] In the penultimate line, replace "used" with "possible". REJECTED: Fine as is. 2. Questions and comments without edits --------------------------------------- [317:30 - 318:10 15.5.2.4p9-10] A description of the case of both being contiguous seems to be needed here. RESPONSE: There appears to be nothing missing. p9 does simply contiguous actual arguments with CONTIGUOUS dummies, as it says "actual argument is simply contiguous OR ...". [330:40 C1562] C1562 is ambiguous. Does the requirement "or that has the ALLOCATABLE or POINTER attribute apply to any argument, or just to CHARACTER arguments? RESPONSE: List is correctly formatted with the Oxford comma, and thus not ambiguous. [336:21,26 C1589,C1592] Function results are very much like INTENT(OUT) dummy arguments. Why is a polymorphic allocatable result prohibited, but a polymorphic allocatable INTENT(OUT) dummy argument is permitted. They both get finalized, and a polymorphic allocatable one might result in invoking an impure final subroutine. Should "allocatable" be inserted before "polymorphic" at [336:26 C1592]? RESPONSE: Function results are not at all like INTENT(OUT) dummy args. C1592 prevents polymorphic INTENT(OUT) dummies of pure procs. [336:35 C1597] It seems that a variable updated by an atomic subroutine ought to have the VOLATILE attribute, else some image might be holding it in a cache while another one is trying to do an atomic operation on it. Does C1597 effectively prohibit the use of atomic subroutines in pure procedures? RESPONSE: Atomic subroutines are not pure, and therefore cannot be invoked from a pure procedure. [337:21 C15101] Is there really a problem to allow an INQUIRE statement in a pure procedure? How about just prohibiting the PENDING= specifier in INQUIRE statements in pure procedures, so as not to cause a wait operation? RESPONSE: That is out of order at this time. ===END===