02-321 Public Review Comment #10 by Richard Maine To: J3 From: Craig Dedo Date: November 11, 2002 Subject: Public Review Comment #10 by Richard Maine From: Richard Maine Sent: Friday, November 1, 2002 6:47 PM To: Donovan, Deborah Subject: Comments on Fortran 2000 Committee Draft The following are my public comments on the Fortran 2000 Committee Draft formally known as ISO/IEC CD 1539-1, Information technology - Programming languages - Fortran. I might later add some more, but as the deadline is approaching, I am sending these to you now rather than waiting and possibly missing the deadline for them. I have segregated these comments by category as typographical errors, wording problems, technical issues, and changes in the selection of features included in the language. All references are to J3 paper numbers. TYPOGRAPHICAL ERRORS The following are fixes for typos, spelling errors, and similarly trivial errors in the CD. [56:Note 4.50 last line] "END FUNCTION POINT_3D" -> "END FUNCTION POINT_3D_LENGTH" [202:28] specifer -> specifier [350:9] depedent -> dependent [377:Note 14.12] "LOGICAL MATRIX_ERROR =3D .FALSE." -> "LOGICAL :: MATRIX_ERROR =3D .FALSE." (One could argue for other colons in this and the subsequent note, but that is a style question. This one is an error). Notes 10.11 and 10.12 have hyphens that should be minus signs. WORDING PROBLEMS W1. The term "binding" is used for two unrelated things, which is likely to be a cause of confusion. It is used in reference to type-bound procedures and in reference to C interoperability. I suggest that this confusion be resolved by using different terminology for C interoperability. Specifically, rename the BIND attribute and BIND statement to LANG (or LANGUAGE) (which I think will be more intuitively clear to most Fortran programmers anyway), rename the ISO_C_BINDING module to just ISO_C, and replace the term "binding label" with "linking label". W2. The use of the word "predictable" in 2.5.5 is either confusing or arguably just plain incorrect and not supported by anything elsewhere in the draft. The only other place in the draft that any form of "predict" appears is in Note 12.26. W3. The phrase "objects or subobjects" at [33:12] is nonsense insomuch as "Subobjects are themselves data objects" ([16:31]). The best fix is to just delete the sentence at [33:12] as it is just a poor attempt at rephrasing what is said correctly at [16:33-34] ("A subobject of a variable is a variable"). There is no need to repeat this on page 33, where it doesn't belong anyway. Likewise, the phrase "object or subobject" at [114:24-25] should be replaced by just "object". The "or subobject" there is worse than useless; it is actively confusing. W4. The term "literal constant" is defined only for source code; it is not something that appears in a formatted file. F90 interpretation 131, published in f90 corrigendum 2, fixed most of the inappropriate uses of this term. However, several remain in subclauses 10.9 and 10.10 of this CD. One example is at [239:27-28], where it says that c and r are literal constants, but then tries to rule out those parts of the syntax of literal constants that don't fit. W5. The term "activation record" appears only once in the draft (in Note 7.9) and is never defined. It seems to me that this will just confuse those readers who don't know what an activation record is and will be obvious to those who do. I'd suggest deleting the sentence. W6. The para at [102:18-23] uses the terms "starting point" and "ending point" inconsistently with their definition and use in the preceeding para. I suggest that the definitions be changed to include the word "value". Ref 02-276, 02-220r1. W7. In the sentence at [3-4] is difficult to parse what "of the scoping unit" modifies. Ref 02-276, 02-221r2. W8. The sentence at [399:37-39] apparently mentions three FORALL constructs, but leaves it confused as to what relationship among them is referred to, or even if it is actually 3 separate ones. Ref 02-276, 02-221r2. W9. The sentence structures in [402:1-9] are so complicated that it is next to impossible to figure out what modifies what, and thus what these sentences actually mean unless you knew the answer before reading them. Ref 02-276, 02-221r2. W10. There is substantial duplication between 2.4.6 and 5.1.2.11, with no obvious criterion for what is duplicated and what is not. The parts that are duplicated in 5.1.2.11 are insufficient to make it hold together without consulting 2.4.6, which makes one wonder why it doesn't just xref 2.4.6 and avoid the duplication. Ref 02-276, 02-240r1. W11. The wording "in contexts where...a pointer refers to a target" [16:32-33] is vague and subject to any number of interpretations. Strangely, that wording was added here in the same J3 meeting at which the same wording in 6.1.2 was deleted for being too vague. The vagueness is, if anything, worse in 2.4.3.1, which lacks the context of 6.1.2. Ref 02-276, 02-241r4. W12. The "and" on [19:5] should be an "or". Likewise on [418:26]. Ref 02-276, 02-241r4. W13. The phrase "may be" is used twice in [19:23-25] where no permission is implied. Ref 02-276, 02-241r4. W14. The word "components" at [41:7] is bolded as a definition, but this isn't a definition. Likewise for the word "finalized" at [59:19]. Ref 02-276, 02-242r2. W15. Some of the "an"s in [114:11-12] should be "any"s. The present wording implies that there is always one and only one such argument, which is incorrect. There could be none or many. Ref 02-276, 02-242r2. W16. The meaning of the phrase "used in any way" at 256:7 is vague. It doesn't mean "referenced". It doesn't mean "appears". The only way to guess what it does mean is to reverse engineer why the sentence might be here and what implementations are likely to do. Ref 02-276, 02-250r1. W17. Wrong use of "may" in Note 16.6. Ref 02-276, 02-252r2. W18. The sentence at [211:30-31] is a word-for-word duplicate of the one at [210:28-29], which is where it belongs. W19. The phrase "unallocated or pointers that are not associated" at [287:10-11] is confusing, grammatically nonparallel, and different from wording used for the same thing many other places in the draft. I suggest adding "allocatables" after "unallocated". Ref 02-276, 02-259r1. W20. The use of the term "ID=3D specifier" at [194:25] is incorrect (operations do not have specifiers), different from usage elsewhere, and directly belies the second sentence of 9.5.1.8, which says that this value is referred to as an indentifier. Ref 02-276, 02-259r1. W21. The use of the term "rounded value" on [230:26] is incorrect; this is not a rounded value of anything. More appropriate would be "rounding value". Ref 02-276, 02-259r1. W22. The condition on w-n being positive does not belong with> the other items in the "where" list at [231:1]. In its current context, it leaves the case where w-n is nonpositive unspecified instead of prohibited. Ref 02-276, 02-259r1. W23. At [237:1-3] it is unclear whether the "if" condition also controls the second clause. Ref 02-276, 02-259r1. W24. The antecedant of "its" at [257:22] is unclear. Ref 02-276, 02-259r1. W25. At [443:12], "can" is used inappropriately where permission is intended. The placement of "only" is also questionable. Ref 02-276, 02-250r1. W26. In Note 4.18, there is no such thing as a bound for an . This probably intends "in" instead of "for". Also the sentence parses ambiguously, possibly referring to a bound for a . Ref 02-276, 02-250r1. W27. It is unclear precisely what "declared in the scoping unit of a module" means on [249:1] and [249:4]. Depending on how that is interpreted, this material might not now address the questions of the interpretations that they were an answer to. Also, the "explicitly" at [249:1] is redundant and thus misleading. Ref 02-276, 02-263r1. TECHNICAL ISSUES T1. I believe it to be a mistake to introduce the concept of iostat values corresponding to "harmless conditions" in the FLUSH statement. This seems inconsistent with all the other IO statements. For example, rewinding or backspacing a file that is already at the initial position might be considered a "harmless condition". Why does it have no effect to flush a file that does not exist, but causes a "harmless condition" to flush a file that is not appropriate for some other reason? This requirement is also arguably contradicted by the first sentence of 9.11. Further the normative text describing this condition uses the adjective "processor-dependent" so much as to make it pointless and ill-defined. The "such as" does not constitute a useful definition, and the bit about inappropriate units is in a note, so all we really have is the statement that processor-defined negative values indicate processor-defined conditions. I think this whole concept is a poorly integrated last-minute addition that stands out as anomalous. It is not necessary for or unique to the functionality of the FLUSH statement. T2. I believe the COMPATIBLE rounding mode to be a mistake (and to be strangely named). The only difference between COMPATIBLE and NEAREST relies on an exact equality test for a floating point value. Furthermore, this exact equality test will often be a test for exact equality to a number that cannot be represented exactly (what binary floating-point number is exactly halfway between the decimal numbers 0.1 and 0.2?). This is the kind of test that programmers are incessantly warned against by textbooks and even by some compilers. It is also manifestly unclear what it is that this mode is supposed to be compatible with. It would seem just as meaningful to name the mode RALPH. T3. Item (2) in 1.6.3 is factually incorrect. F77 did not leave the SAVE attribute processor-defined under any circumstances. It is quite explicit about initialized variables becoming undefined if they have been modified and have not been specified in SAVE statements. The only thing processor-defined here is what the procesor will do with non-standard code that references the undefined variables. That is not appropriate for this section. And even if it is appropriate, the statement here now is factually incorrect. T4. Item (3) is likewise about non-standard code. As the item mentions, the f77 standard said that it was not allowed to read more data than a record contained. Period. Any program that did so was therefore, non-standard. This item is thus not about standard-conforming code that now has a different interpretation. This is about code that was formerly non-standard, but is now standard. There are many, many codes that were formerly non-standard but are now standard. This includes any code that uses new f90 features. I see no reason to single out this one. If we do mention it, we need to avoid incorrect statements about it (such as that valid f77 code could have a different interpretation in f90 because of this). T5. The terms "local entity" and "global entity" seem to be misused regularly. Introduction of the term "local name" would probably go a long way towards fixing these confusions. Paper J3/01-163 brought this issue to my attention; I think it was a good start, but didn't fix these terms. For example, the section on host association says that if a name appears in any of a bunch of contexts, "then it is the name of a local entity". This is apparently intended to distinguish it from host-associated names, but of course, it doesn't. And the phrase "local entity of" (as used in the glossary entry for "automatic data object") makes no sense. Section 14.1.1 talks about "a name that identifies a global entity" in a way that apparently forgets that global entities may be identified by local names (via rename). (surprised there hasn't been an interp on that one because it sure sounds like it is saying that a widespread practice is illegal). I do note that the terms "global ent" and "local ent" (I searched on these short forms to avoid missing plurals) are almost entirely restricted to c14. The only other appearances of "local ent" are two in the glossary - one is the glossary definition of the term itself; the other is the incorrect usage cited above. The only other appearance of "global ent" is one incorrect one in c12 (where it confuses the name and the entity). I think almost all of the occurances of "local entity" would be better replaced by "local name" (which I see 6 uses of, but no definition). "Global name" also appears 6 places, none of them being in a definition. Heck, seems like many of the occurances of "local entity" already end up looking like "name that identifies a local entity". Not all the uses can be so replaced (after all, there is brief discussion of local entities that don't have names), but I think most cases can. The term "local name" seems more intuitively appropriate anyway. At least to my ear, saying that something is a local name in a scoping unit is a lot less likely to give an incorrect impression that the named entity is somehow local *ONLY* to the scoping unit in question. T6. The section on the procedure declaration statement (12.3.2.3) has a whole bunch of syntax with no associated meaning. It adequately discusses the , but that's about all. It says not a single word about what any of the mean. We don't need to say much about them here, but we *DO* need to say something. As is, we don't even say that they specify the procs in question to have those attributes. We ought to at least say that, and then xref the appropriate sections. Should do the xrefs in such a manner as to also pull in all the associated constraints/restrictions. For example, nothing here says that the entity has to be a dummy argument to have the optional or intent attributes - or that the entity had better not be a dummy argument of it has the save attribute, etc. Also, I see no hint here about what the =3D>null() is supposed to mean or what contexts it is allowed in. Perhaps that one can also be referenced. But if so, note that we also use the bnf in procedure pointer components, where I think the syntax means something slightly different (default initialization vs object initialization). T7. In the get_command, get_command_argument, and get_environment_variable intrinsics, it seems inconsistent to have a nonzero status return for character length truncation. Such truncation is not an error or specially signaled condition in any other context, such as values returned from io specifiers. It isn't an error if you try to read a line into a character variable and the character variable is too short to hold the whole line. It isn't an error on assignment. The optional length argument does provide a way to detect this condition if the user wants to for these intrinsics. T8. The descriptions of C_LOC and C_F_POINTER are so incomprehensible as to constitute technical, rather then mere wording flaws. The descriptions are full of requirements that are assumed rather than stated, and other requirements that contradict each other by failing to state assumed conditions. For the simplest example, [384:20] says without qualification "FPTR shall be scalar", although there is lots of discussion of cases where it is an array; this requirement is clearly intended to apply only in some cases, but that isn't stated. Ref 02-276, 02-230r3. T9. There is no such thing as "an interface body that is not in an interface block" [78:34-35]. Ref 02-276, 02-238r2. T10. It makes no sense to say "a dummy argument,... or a local entity" at [252:13-14], insomuch as a dummy argument is a local entity. This probably meant to say "local variable". Ref 02-276, 02-240r1. T11. The term "subobject selector" is used in 12.4.1.6(5), but never defined. Ref 02-276, 02-241r4. T12. The "in an actual argument list" at [20:15] is almost certainly incorrect. THis probably should be "as an actual argument". Ref 02-276, 02-241r4. T13. The sentence at [41:20-21] directly contradicts material in 4.5.1.8. It also misuses "when" to refer to a place instead of a time. The sentence adds nothing useful and is out of place anyway. Ref 02-276, 02-242r2. T14. The word "specific" at [55:5] rules out overriding of final bindings. I doubt this was the intent. This should probably be "nongeneric". Ref 02-276, 02-242r2. T15. I don't understand the inclusion of abstract interface at [260:5], particularly as that inclusion was argued to be for compatability with similar words in 5.1.2.6, which were modified at the same J3 meeting to remove abstract interfaces from ths list there. Ref 02-276, 02-244r2, 02-238r2. T16. At [45:27] the draft leaves the kind of integer unspecified in the case where the omits the optional . The material in 5.1.1.1 does not cover this case because there is no type specifier here. (The syntax is identical to that of a type specifier, but it is not described as one; perhaps it should be). Ref 02-276, 02-247r1. T17. In 9.10.4 there are two references to constants, which are subject to the same misinterpretations as similar forms fixed by 02-249r1. The phrase "of the ISO_FORTRAN_ENV intrinsic module" should be added before both references to 13.8.3.2.x here. Ref 02-276, 02-249r1. T18. Acording to [255:30-33], all abstract interface blocks are also specific interface blocks (as they lack generic> specifications). This is clearly wrong. Ref 02-276, 02-250r1. T19. Should "END ABSTRACT INTERFACE" be allowed at [254:23]? T20. The change of the position of the word "only" at [131:9], intended to be editorial, constitutes a major unintended technical change from previous standards. This requires the processor to do what was formerly at its option. Ref 02-276, 02-250r1. T21. The positioning of the word only at [272:22] and [272:32] results in nonsense. This is supposed to be talking about being "only specific", but instead is now talking about "only in a scoping unit". Ref 02-276, 02-250r1. T22. The omission of "only" from the heading of 12.4.4.2 is another technical error. It is critical that the procedure is established to be "only specific", as opposed to specific (and possibly also generic). Ref 02-276, 02-250r1. T23. The issues involved with the output argument of defined assignment and derived type input seem similar enough that I would think the same INTENT attribute choices would be appropriate for both. Defined assignment allows either intent(out) or intent(inout) at the user's choice. Derived type input requires intent(inout). Is there reason for this apparent inconsistency? Ref 02-276, 02-269r1. T24. The "specific or type-bound" at [397:15] is confusing because the type-bound procedures that it refers to are also specifics. The wording at [56:3] is probably misleading in this regard. Ref 02-276, 02-270. T25. The word "contains" at [401:28] is ambiguous and confusing in this context and would probably be better replaced by "is the host of" (as opposed to the other possible reading as just "is"). Ref 02-276, 02-270. FEATURES F1. I propose that the enum feature be deleted. As currently constituted, it adds almost no functionality to the language. Except for the BIND(C) case, it is nothing but another syntax for functionality that we already have. The only new functionality of the feature is the kind determination of BIND(C), which doesn't appear to be much of an issue in practice since apparently most C compilers use C int for all enums. If a future revision ever does add a strongly typed enum feature, the overlap between that and the current one will contribute to the language seeming bloated and haphazard. I believe this potential negative impact to outweigh the small benefits of the current feature. Adding a strongly typed enum feature now is not reasonable in my opinion. It would have too many potential interactions with oher features and would consequently cause substantial delay in the standard. Deletion of this feature has little impact on the rest of the standard. The enum feature is currently nothing other than an alternate syntax for defining a type alias and a set of named constants; no other features depend on whether this or some other syntax for the same thing is used. F2. I propose that an intrinsic to execute a system command be added. The CD adds intrinsics to obtain information about the command used to execute the Fortran program. The ability to in turn execute some other program is the other side of the same coin, often asked about in almost the same breath. Almost all processors have such a facility. It begs for standardization. Yes, the interpretation of the command depends on the processor. Nonetheless, this is a very useful and widely used facility. It is also trivial to add to the standard, being just an additional intrinsic with no special interactions. This functionality is indirectly available via C interop, but I think it merits direct support, just like the intrinsics to obtain command-line information have direct support in the CD. -- Richard Maine | Good judgment comes from experience; maine@altair.dfrc.nasa.gov | experience comes from bad judgment. | -- Mark Twain References 02-007r3, Fortran 2000 Committee Draft [End of J3 / 02-321]