J3/06-263r1 Date: 3 August 2006 To: J3 From: Aleksandar Donev Subject: Notes on clauses 8-13 of F2008 draft References: 06-007 I split the comments into several categories: 1) Simple editorial corrections 2) Requests to clarify or change wording 3) Technical issues that I do not understand or I find badly designed and in need of fixing. _________________________________ Editorial corrections _________________________________ 1. [189:12] Add "not" after "and shall" 2. [205:?] At the end of the second line of Note 8.41, replace ". For example:" with ":" 3. [207:30] Replace "are capable of representation in the processor" with "the processor can represent". 4. [217:33] Replace "is not permitted" with "shall not be executed". 5. [247:27+] In the last line of Note 9.62, fix the opening quotes to be `` instead of ''. 6. [303:?] In the last line of Note 12.5, add a CALL before EXT3. 7. [303:?] Reword the first sentence of Note 12.6 to say: "...have dummy arguments that are procedures with explicit interfaces and have dummy arguments of a derived type defined in the module." 8. [305:2+] In Note 12.8, change the dimension spec of B2 from "SIZE(B1)" to ":". There are subtle impacts of making it explicit shape---for example, it will cause copy in/out in a variety of situations. 9. [306:1+] In the last two lines of Note 12.10, the parenthesis around the second arguments seem needless and will confuse the reader. 10. [307:10] Add a new line before R1216 and also fix the font in . 11. [324:4+] In the penultimate line of Note 12.38, replace "A=" with "A(6:10,2)=". 12. [326:24] Isn't C1243 tautological---this is how dummy argument is defined? 13. [334:14] In the first line of C1282 replace "in common" with "in a common block". 14. [334:18] Add a space before (16.6.7). 15. This is probably noted already, but the new intrinsic STORAGE_SIZE is missing from 06-007. 16. [381:6-7] We should typeset "array-element" in font code. 17. [382:8-15] This text should be moved to the left. Similarly for [414:10-18]. 18. [390:23+] The unlucky Note 13.13 should be talking about IMAGE_INDEX, not THIS_IMAGE. Similarly for Note 13.23 at 433:10+]. 19. _________________________________ Changes of wording _________________________________ 1. [190:?] In Note 8.21, change "construct will allow" to "construct would allow" and add "potentially" before "significantly improve performance". 2. [199:8] The statement "All images of the team shall execute a SYNC_TEAM statement" does not appear for SYNC_ALL. I am not sure what it even means. Either the program will hang indefinitely or all images will execute a SYNC_TEAM. Rewording along the lines of "until all images of the team have executed a SYNC_TEAM statement with a value of that was constructed..." seems more appropriate. John: "See the edit for issue 35. We need to say that all images use the value returned by a collective call of FORM_TEAM for the team." 3. [202:?] Note 6.36 is completely wrong! This code performs exactly the same action as SYNC_ALL, however, in a likely less-efficient manner which forces all communication among images to go through image 1. To see this, note that each image 2-NUM_IMAGES() must wait for image 1 to finish its own SYNC_TEAM, which in turn waits for all other images to also call their SYNC_TEAM. This note can be deleted. 4. [290:23-25] C1107 needs to be rewritten correctly---at present it neglects subcomponents. See also C1118 at [294:14-15]. 5. [298:4-5] Delete "the internal procedure shall not be argument associated with a dummy procedure (12.5.1.6)" 6. [298:28] should be added to the characteristics of dummy data objects in 12.3.1.1. 7. [309:22] There should be an edit prohibiting from being a co-indexed object, so that one cannot do (or think one is doing) remote calls. Since the dynamic type will be the same on all images, the only reason for using a co-indexed is the PASS attribute. However, it is not clear our design of PASS is actually consistent with the constraints on dummies when the actual is co-indexed, so I think for now we should constrain this: [163:30+] Add new constraint after C729: C729b (R741) The in a shall not be a co-indexed object. 8. [310:1+] I find the "feature" described in Note 12.16 unacceptable. The of a should not be allowed to be a co-indexed object. The same procedure may have different physical addresses on different processors in distributed architectures. The machines in the cluster may be of a different architecture---it is NOT even the same a.out, yet alone at the same virtual address. So taking a procedure pointer from one image and calling it on another is hard to implement without any real benefits. In fact, I think this is already prohibited by the combination of C729 and C616, since ultimate components include pointer procedure components. Maybe this was accidental? Just in case, here is an additional edit: [163:30+] Add new constraint after C729: C729a (R741) The in a shall not be a co-indexed object. Unfortunately this does not allow combining the PASS attribute with co-indexing. 9. [310:1+] Given the above two points, Note 12.16 should be replaced with: NOTE 12.16 A co-array is permitted to be of a type that has a procedure pointer component or a type bound procedure. Such a procedure is not permitted to be invoked through a co-indexed object because this might require an action to be taken by another image. CALL A[I]%PROC(X) ! Remote procedure reference not allowed [end NOTE] 10. [316:4] At the end of C1236, add "that does not have the CONTIGUOUS attribute" 11. [316:9-10] This sentence should be: "If the dummy argument is an allocatable co-array, the actual argument shall be an allocatable co-array with the same rank and co-rank" Surely we want to allow an actual that is an allocated co-array and a dummy that is not allocatable? If so the "if and only if" is not appropriate. 12. [320:4-5] After "assumed-shape array" add "that does not have the CONTIGUOUS attribute". The text at [321:9] seems to be a verbatim copy? 13. [335:9+] In the last paragraph of Note 12.49, what does "library procedure" mean. I know of plenty of library procedures that are not PURE---a library must eventually produce some output too. 14. [336:2-3] After "shall be a scalar dummy data object" add "of co-rank zero" (or "that is not a co-array"). 15. [336:6-8] C1291 should allow using dummy%kind instead of KIND(dummy). Also, length-type parameter inquiry other than the character LEN should be allowed. 16. [336:8+] Reword Note 12.51 to take into account impure elementals: "If an elemental subprogram is a pure subprogram then all of the constraints of pure subprograms also apply." 17. [336:15] and [336:8] I believe we need a note explaining that if the elemental procedure is pure, the processor can actually apply the scalar function/subroutine in any order. 18. [360:37] The word "compatible" should be qualified, probably "bits compatible" (once that term is well-defined). 19. [438:13+] We should give an example of using this function, maybe to initialize a static variable: CHARACTER(LEN=*), PARAMETER :: OPTIONS=COMPILER_OPTIONS() 20. [438:22+] What exactly is the point of the last sentence in Note 13.25? I thought we should be encouraging the user to save the options to a variable so as to make sure the compiler puts that in the object code. Or are we encouraging compilers to always include this info in the object files? _________________________________ Technical questions _________________________________ 1. [181:30-31] and [181:3-4] (C808) Why do we prohibit all vector subscripts instead of only many-one array sections? 2. [181:21-29] Why is there no mention of the POINTER and ALLOCATABLE attribute here. At the very least, we should reference 16.5.1.6. 3. [189:17-19] What is the point of making the pointer-association status processor-independent, as opposed to simply undefined? 4. [197:4-14] Do these rules adequately cover variables becoming undefined, or the allocation or pointer association status of variables being changed. Does "referenced or defined" cover it all? 5. [301:8] Why don't we allow an optional :: in R1206? 6. [301:42-43] What is the technical reason behind C1210? It seems to me to make it much harder to write module procedure interfaces without a real reason. 7. Following our new addition of allowing a POINTER dummy to correspond to a non-pointer actual and not be argument associated with a dummy argument, (rather, pointer associated with the TARGET dummy, see [312:3]), it seems to me there is a difference now between: "corresponding dummy/actual" (in argument position) and "associated dummy/actual" (there may not be one) It seems to me these are not used consistently. For example, when we say "the dummy argument" while talking about an actual, do we mean the corresponding one or the associated one? Here are some places I noticed where this makes a difference. There may be others---this is subtle: a) [197:13] This says "argument associated entity" even though it should refer to the corresponding actual. b) [312:9] This should say "declared type of the associated dummy argument", since the type matching is covered under the pointer assignment of the dummy pointer to the actual target and should not be replicated in different places (for the sake of future revisions). c) [313:7] "the actual argument shall have" means "the corresponding actual argument", right? Does the TARGET of a CONTIGUOUS pointer have the CONTIGUOUS attribute? 8. [313:7] The restriction "the actual argument shall have the CONTIGUOUS attribute" is horrible and makes the presumed "feature" practically useless. The justification that was given in the design paper for the feature of pointer dummmy with nonpointer actual (06-108r1) was that "undefined pointer" association status should be avoided. So now we have a useless but safe feature---we through away the baby with the bath water. A user can easily subvert this and get a program crash: interface subroutine sub(y) real, pointer, contiguous :: y(:) end subroutine end interface REAL, ALLOCATABLE :: x(:) real, pointer, contiguous :: z ... CALL Sub(x) ! Not allowed because x does not have CONTIGUOUS attr z=>x CALL Sub(z) ! Is allowed z=>x(i:j:k) ! May or may not be contiguous at runtime CALL Sun(z) ! Is allowed, but may crash anyway In 06-108r1 it is suggested that the decision not to give the CONTIGUOUS attribute implicitly to allocatable and explicit shape arrays be revisited. This is a separate issue on its own. An alternative is to change the restriction in [313:7] to say "the actual argument shall be contiguous". Unless we make pointer assigment "compile-time safe", argument association won't be safe either, and we are just adding silly restrictions on the programmer. 9. [316:7+] I find Note 12.27 confusing and misleading. Why is it talking about the actual argument being defined asynchronously when it is the dummy that has the ASYNCHRONOUS attribute? Why do we even prohibit copy in/out when the dummy has asynhronous? Can't the asynchronicity be confined within the procedure itself. It is really the actual being modified while the procedure is executing that is the problem. I believe this "design" needs major fixing. 10. [317:9-10] Why aren't these numbered constraints? It seems to me explicit interfaces are required so this can be checked at compile time. Just curious... 11. [317:1-3,4-5] Before going into the flaws of the edits, I want to clarify what the intention is. What we want to achieve is that if the dummy is a co-array, there will be no copy in/out of the actual. There are two approaches to this: Make this enforceable at compile time, or, make it a constraint on the user. The edit at [317:1-3] talks about having the CONTIGUOUS attribute, which seems to aim at compile-time checking to make sure that copy in/out cannot happen at runtime. On the other hand, [317:4-5] is not compile-time checkable, but depends on whether the array section is actually contiguous. We need to decide what we want. I would suggest only runtime checking. Only the sentence at 317:4-5 is sufficient, and should be reworded to say: "If the dummy co-array is not of assumed shape or has the CONTIGUOUS attribute, the actual object shall be contiguous (5.3.6)." 12. [321:4-322:2] This seems to be a verbatim copy of item (1) at [319:43]. I do not understand what the difference is and why this is duplicated twice. 13. [327:15] Is C1254 really necessary. We have now enhanced the usability of internal procedures considerably by allowing them to be called from outside the host. I envision a conversion of some "callbacks" into internal procedures. It seems like bad design not to allow them to have internal subroutines themselves, unless there is an implementation problem? 14. [327:41-42] Why can't a function invocation return NULL()? It seems perfectly useful and well-defined. Why is this restriction on function reference (a run-time issue) in the section on function definition (compile-time or source-code issue)? 15. [335:8] Can a pure procedure have co-array dummies? Does C1287 apply to dummy arguments? 16. [394:2] I find the IS_CONTIGUOUS intrinsic (13.7.93) terribly useless given the restriction on the actual argument: "It shall be an assumed-shape array or an array pointer." We have several objects for which it is processor-dependent whether they are contiguous. There are also things like array sections for which one can only know whether they are contiguous at runtime. Given our design of IS_CONTIGUOUS, one cannot write: REAL, POINTER, CONTIGUOUS :: x(:) IF(IS_CONTIGUOUS(some_array%real_component)) x=>some_array%real_component One cannot do the pointer assignment first, and then test for contiguity, because by then the program would already be illegal! We should allow any data object to be the actual of IS_CONTIGUOUS, or at the very least, any array object.