J3/01-278 Date: August 4, 2001 To: J3 From: Dick Hendrickson Subject: Chapter 2 comments 1) Page 8, note 2.1. Add a sentence "Rules that do not begin with R2 are more fully described in the appropriate chapter." 2) Page 11, C201. Should this constraint immediately follow R208? See e.g. R601 to R607 3) Page 11, section 2.2. I find the distinction between external subprogram and the CH12 external procedure confusing. CH12 allows a C procedure to be an external procedure; but there is no hint in the CH 2 syntax rules nor in 2.2 that a C procedure is anything. I don't have a suggestion for what to do here. Maybe just a note ala Note. There is also a class of procedures, called external procedures (12.1.2.2), that may be defined in another language. These procedures are not described in the syntax rules. Maybe 2.2.3.1 is good enough. 4) Page 12 2.2.3 Delete the reference to 9.5.4.4.3 in the middle. Other things (FINAL I think) can also invoke a subroutine. We don't need a list here. 5) Page 12, 2.2.1. The last sentence directly contradicts the note when it says the things may come in "any order". The note says "modules first". I suggest changing the normative "any order" to "processor dependent order" and let the note explain what that order might be any why. Might be tricky to word because we don't want to imply that subroutines must be compiled before they can be called, etc. 6) Page 13, 2.2.2.4 4th line. After accessible add "to all program units within the module and" Also, change "request access" to "obtain access". Line 5, also change "request" to "obtain" and "module" to "module via a USE statement" 7) page 13, 2.3 change last "and" clause to "and not all executable statements may appear in all contexts. to allow for things like PRINT can't be in a WHERE block and CYCLE can't be in a nonDO block. 8) Page 13 2,3,2 next to last line. Obsolescent font for DATA statement implies to me that the DATA statement is obsolescent. It's only the "appearing" that is obsolescent. Need to refont the sentence. 9) Page 13, 2.3.1 executable statements. Things like SUBROUTINE do more than configure the environment. For INTENT(OUT) dummies they cause evaluation of the initialization stuff. I'm not sure what goes on with polymorphic stuff as far as magic invocation of user functions. But a DIMENSION statement for an automatic array surely triggers execution. Both trigger actions. 10) Page 14, table 2.2 Does no interface block in a block data limit the way we can use the new(?) forms of initializers for derived type things? 11) Page 14, table 2,2, note 2. Don't derived type definitions contain type declarations which are part of Misc. decls? 12) Page 15, 2.4.1, second paragraph. Does this need to be reworded to account for parameterized derived types? This definition sounds like it applies to KIND type parameters, non NONKIND ones which I don't think control syntax, operations, etc. I may be confused about this. 13) Page 16, 2.4.1.2, line 5. Change "structure constructors are available" to "a default structure constructor is available". The last sentence of the paragraph says the others are only available if you provide them. 14) Page 16, 2.4.2, third line says things are ultimately specified in terms of things that are of intrinsic type. 4.5 (page 38) gives a technical definition for ULTIMATE COMPONENTS that allows them to be allocatable or pointers. 15) Page 16, 2.4.3.1 second paragraph. I read that to say the real part of a complex variable can be defined without defining the complex part. I don't think that is true. 16) Page 16, 2.4.3.1 last 5 or 6 lines. I think we need a note to say that char_array(1:5)(2:3) is an array and that the substringing part doesn't matter. It's deducible from the text (I think) but it sort of looks like we just forgot to mention it. 17) Page 16, 2.4.3.1, last line. Yes, but can also reference them as array sections, etc.. since by 10 or so lines before a named complex array is a complex object, 18) Page 18, second paragraph, second line. seems to say scalar = array is OK since scalar and array are conformable and scalar = scalar is defined. 19) Page 18, 2.4.6 POINTERS. Need to say association status may also be undefined and can't then be ref or def? 20) Page 18, 2.5.5, second paragraph. Does OOP add any more magic ways to refer to a procedure? Also, probably need to add DTIO as a way to reference a procedure. 21) Page 20, 2.5.10. This seems pretty general in terms of companion processors. For example I might use a F2K compiled code to call a subroutine compiled with g77. That seems to be allowed. Then the last paragraph of 2.3.4 requires the C exit() to be executed on termination.