J3/06-210 Date: 28 July 2006 To: J3 From: Aleksandar Donev Subject: Notes on clauses 1-7 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) Things I am confused about (these may be technical issues) These do not include issues concerning co-arrays and responses to Internal Notes. _________________________________ Editorial corrections _________________________________ 1. [xv: Shouldn't the "G0" edit descriptor be added to the list of new features? 2. [11:52] Replace "anywhere that any" with "anywhere a" 3. [20:25] I believe "rectangular" only applies for two dimensional patterns. See also [119:11]. 4. [33:19] is not formatted properly 5. [33:27] Replace "it shall be" with " shall be" 6. [35:28] The phrase "physically replaced" seems inappropriate. Simply "replaced"? 7. [39:] In Note 3.14, there is a MACRO missing from in front of the DO. 8. [65:2-3] After "disassociated", add "or associated with specific targets" 9. [65:27] Add "and" before "does not have" 10. [88:17+] In Note 5.8, add a new line before the second REAL 11. [90:14-15] Delete the sentence "The value of a lower...may be positive, negative, or zero"---it seems tautological. 12. [90:21] Add "non-allocatable" before "nonpointer" 13. [91:22] Add space in "ofa" 14. [94:?] In Note 5.16, second line of second para, delete "there is any possibility that". 15. [120:9] I believe the initial "Exactly one shall have nonzero rank" is needless duplication of C617. 16. [124:25,30] Replace "SOURCE=" with . MOLD= is also a perfectly acceptable way to specify the dynamic type. 17. [158:30] There is a formatting problem with _________________________________ Changes of wording _________________________________ 1. [22:4] The first sentence does not include the newly added ability to perform pointer association via explicit initialization or default initialization. 2. [34:36-37] C313 needs to be rewritten so that it does not have three negatives. I do not understand what it is trying to do. Can the first be DEFINE or EXPAND? If yes, then why are these separate items in the BNF for R322? I would have thought that a body statement cannot be any of the special macro statements, namely anything starting with MACRO and also DEFINE MACRO and EXPAND. As a specific example, can a macro define a macro with a variable number of arguments, where the number of arguments is an argument of the top-level macro? 3. There is a clear provision for macros defining macros. Here is an attempt at an example of using such a macro---to be included in a Note or Annex C: --------- ! Macro that defines a macro which assigns a value to an array element DEFINE MACRO :: assign_shortcut(rank) DEFINE MACRO assign_%%rank(array,indices,value) MACRO INTEGER :: i array(indices(1),&& MACRO DO i=2,rank indices(i)&& MACRO END DO )=value END MACRO assign_%%rank END MACRO assign_shortcut ! Create assignment macros for all ranks MACRO DO i=1,15 EXPAND assign_shortcut(i) MACRO END DO ! Now use the rank-3 assignment macro: REAL, ALLOCATABLE :: A(:,:,:) INTEGER :: indices(3)=... EXPAND assign_3(A,indices,5.0) --------- 4. [37:1] I find "statement-dependent" in item (3) too vague---maybe say "Macro statement processing". The expansion of macros is in a sense iterative, expanding MACRO and EXPAND statements until there are none left to expand. This was not really clear to me from reading the description. 5. [38:20] I believe that we should be specific that token replacement and concatenation are the ONLY forms of expansion that occur. 6. [86:12+] In Note 5.3, replace the end "in a module where it is PRIVATE" with "that module". 7. [79:11+] Near the end of Note 4.66, the phrase "interoperable values" which I don't think is defined. Maybe "the types will be interoperable"? 8. [87:19] I find it very weird that the "not the real or imaginary part..." is separated at the top, before the list. It should go under arrays section. 9. [89:5] I believe what this is trying to say is that a "co-array shall not be a constant or a function result". This seems clearer and more specific to me. 10. [89:7+] In Note 5.10 delete "on an image" from "allocated on an image" 11. [89:15+] In Note 5.11, we should add an example of an assumed-size array and also clarify that the array pointer and allocatable examples are deferred-shape arrays. 12. [117:2] We should change the term "structure component" since it can be read to mean "component of a structure" rather than being a made-up term. A structure is scalar, but "structure component" can be an array. I find this very weird and confusing. 13. [117:11] We need an equivalent to C614 for the . At present this seems to be a plain restriction (non constraint) at [123:5]. 14. [126:15] Shouldn't we add "as if via intrinsic assignment" or something alike to the end of the paragraph. The current phrasing "the value of becomes that of " does not seem to make sense for the case when is scalar and an array. 15. [145:13-21] Is very repetitive---it would be useful to rewrite it. 16. [164:35] Here we say "LBOUND applied to the corresponding dimension of data-target". For intrinsic assignment we say "corresponding element of LBOUND()". We should be consistent. 17. [165:?] In Note 7.49, we should add an example of rank-remapping using CONTIGUOUS. Something like: REAL, CONTIGUOUS, POINTER :: A(:) REAL, CONTIGUOUS, TARGET :: B(:,:) ! Dummy argument A(1:SIZE(B))=>B ! Flatten a rank-2 array _________________________________ Technical questions _________________________________ 1. [56:8] Is "ultimate component of a type" well-defined? We have subcomponents of an object, and ultimate components of an object. How about of a type? This is important because we have used this phrase heavily, especially for co-arrays. 2. 3. [84:23] Why not replace the BNF with NULL() and get rid of C512? 4. 5. [87:5] Can one please give me an example of a procedure declaration with the BIND(C) attribute? 6. [88:17] Isn't non_contiguous_array%component always non-contiguous? 7. [120:1] We had an e-mail discussion about the "does not require the shape". A subroutine reference such as: CALL Subroutine(assumed_size_dummy%component) does not "require" the shape of assumed_size, yet we want to prohibit it. 8. [133:18] I believe we should add a constraint prohibiting an expression primary that is a co-indexed object with pointer ultimate components. Parenthesizing such an expression would require making a local copy of the object, which is not allowed if there are pointer components. ______________________________________________________