J3/01-373 Date: November 14, 2001 To: J3 From: Dick Hendrickson Subject: Chapter 2 comments, updated from meeting 158 This is an update of 283/R2 from meeting 158. Page, etc., numbers have been updated to the current 007/R4 PDF version 1) Page 9, 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[18], 2.2.3 Delete the reference to 9.5.4.7 in the middle. Other things (FINAL I think) can also invoke a subroutine. We don't need a list here. 5) Page 12[8-9], 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. Also, the note has a bad line break or missing blank line. 6) Page 13, 2.2.4 Line 15 After accessible add "to all program units within the module and" Also, change "request access" to "obtain access" twice on line 16 Line 17, and "module" to "module via a USE statement" 7) page 13[20-21], 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[37] 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) withdrawn 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[36-38], 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, not non NONKIND ones which I don't think control syntax, operations, etc. I may be confused about this. 13) Page 16[14], 2.4.1.2. 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[21], 2.4.2, third line says things are ultimately specified in terms of things that are of intrinsic type. 4.5 (page 40[33]) gives a technical definition for ULTIMATE COMPONENTS that allows them to be allocatable or pointers to things of derived type. This is a confusing choice of introductory words. 15) Page 16[35], 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) withdrawn 17) Page 17[3], 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, PROPOSAL, Add "also" after "may" 18) Page 18[14], 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[30], 2.4.6 POINTERS. Need to say that association status may also be undefined and can't then be ref or def? 20) Page 19[33], 2.5.5, second paragraph. Does OOP add any more magic ways to refer to a procedure? Also, need to add DTIO as a way to reference a procedure. Actually should delete the list since this section is merely general blather and it's tough to keep this kind of list up-to-date. 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, page 15[25-28] requires the C exit() to be executed on termination. I think page 15 needs to be tightened up to say the companion is a C processor.