J3/01-255 Date: 22 Jun 2001 To: J3 From: Richard Maine Subject: Edits incorporated in 01-007R2 This paper describes the changes in J3/01-007R2 relative to the previous f2k draft, J3/01-007R1. All page/line references are to J3/01-007R1 unless otherwise noted. The change bars in 01-007r2 are relative to 01-007r1. This includes edits from papers (all 01-) 189r1, 193r1, 194r1, 195r1, 196r1, 197r1, 198r1, 203r1, 204, 205, 206, 212, 213r2, 214r1, 215r1, 216, 217r1, 218r2, 223r2, 225r2, 226r1, 227r1, 228, 229, 230r1, 233r1, 234r1, 235r1, 236, 237r1, 238, 239, 241, 242, 243r1, 244, 245r2, 246r1, 247, 249r1, 250, 251, 252r1 misc typos and fixes not in papers 321:4 Fix typo in "representable". 196:13 Delete "Figure". [102:45] "When" -> "If" paper 01-189r1 as is paper 01-193r1 part 1.1 as is paper 01-193r1 parts 1.2 and 2.1.2 with the following changes The index entries for "statement,*" use "statements" plural. The section at 338:31 was deleted later this meeting. paper 01-194r1 with the following changes Avoided saying "processor processor" in the pg 4 edit. paper 01-195r1 as is paper 01-196r1 as is paper 01-197r1 part 4 with the following changes The [41:4+] edit almost duplicates an edit in the same place from paper 01-247. Did the one from 01-247. [47:37] I can't find anything in 5.1.2.11 that has any connection to initial association status. Putting such an xref here seems just confusing. Perhaps somewhere else in the area, but not right here. Perhaps on the first or second sentence in the section? For now added no xref. paper 01-198r1 part 1 with the following changes Did not do the edit at [73:39,40]. Consulted with /data and they agree that this edit would have omitted the dummy argument case. Also deleted "in the ALLOCATE statement" at [74:38]. Allocation can now be done in other contexts, so this was incomplete in addition to being duplicative. I don't think the edit at 75:1-2 is needed, but guess it doesn't hurt. (The paper's abbreviation of the sentence misrepresents its structure.) Did the edit as specified. [76:16] changed the second "the" on the line. [78:22] The citation of 65:5-6 is not relevant because the intrinsic attribute does not apply to data objects, which is the only thing that 65:5-6 mentions. But the line is still duplicative because all it does is call attention to 12.3.2.4. I did the deletion as specified. paper 01-203r1 with the following changes [97:24] I think the "which" more appropriate here (and the instructions did say "if you like"). [97:38] I can't see that the commentary on the r1 has any relevance to the edit, though the edit itself looks fine (and the commentary on the r0 seems appropriate). Did the edit as is. Did nothing about number agreement, which the comment seems to be implying is at issue (and which looks ok to me). Added a "the" while in the area. [99:5-6] This proposed "editorial" change of "when" to "if it is" introduces an incorrect technical change. Although "when" inappropriately refers to time, "if" is worse. With "if", a single usage that meets the stated criterion would be sufficient to define all uses of the component as being subobjects. Indeed, we often use wordings like "if it is used" to mean exactly such global implications deduced from a single appearance. I reworded this sentence to use "where" instead of either "when" or "if". Also, kept the "dereferenced" bit, though with the "where" changed to "in which" to go better with the revised sentence. I would say that something like "P => T" does "pertain to the target", so that wording is too imprecise to capture the intended meaning. The term "dereferenced" ties it down unambiguously. [104:36-37] Without other changes, this edit would be confusing. The reason for the former "for an object" wording was that multiple objects may be specified in a single statement, making "the object" (or "the ") ambiguous. However, with the proposed editorial change to make it explicit what rule each constraint ties to, this should become clear. Edit done as specified. However... I'm doing this paper before that editorial change, so I'll leave this as a reminder that this constraint really needs such a tie (and needs to get it right). Someone ought to check this if I forget to. [105:32] I considered doing this edit and writing an unresolved issue about it, but instead just did not do the edit. It has multiple problems. First, the explanation given for the edit is a complete nonsequitur. It is true, as the explanation notes, that kind type parameters may not be deferred, but that is completely irrelevant to this sentence. We are not talking about deferred type parameters, and we don't want to. We also are not talking about kind type parameters. This sentence is explicitly about nondeferred type parameters (thus the words "nondeferred" and "nonkind" in it). Those "non" parts are sort of important. Nondeferred type parameters may in general be either kind or nonkind. Thus the qualification "nonkind" is not redundant. Second, with this edit, the sentence would contradict the constraint one page earlier that requires type compatability. The constraint requires compile-time diagnosis of a disagreement in kind type parameters, while the revised version of this sentence requires that the code generate a run-time error condition (which is perfectly legal - a program could even legally use this as a somewhat obscure way of setting the iostat= variable to a guaranteed non-zero value). For kind type parameters, the constraint says that disagreement is not allowed, but this sentence now says (since it no longer excludes kind parameters) that disagreement causes an error condition (which is very different from being disallowed; it means the code compiles, but either aborts or sets iostat at run time). I did this edit in deference to the committee vote, but I think it makes a contradiction. [108:19+] I'd have thought it simpler to add the one constraint implied by the explanation instead of adding a new syntax rule that largely duplicates that for . (And part of the duplication is a constraint). But I did it as specified. I suppose one might be looking forward to possoble future additional differences. papers 01-204 specified edits as is specified edits were the ones at 111:3 and 119:5 paper 01-205 with alternative 3 as is paper 01-206 as is paper 01-212 as is paper 01-213r2 with the following changes I think that we should still allow subroutine calls as part of Fortran programs. Therefore, I kept the name of the bnf term for a subroutine call as , which is used elsewhere, rather than renaming it to , which isn't. Besides which, we attach special significance to bnf terms ending in <-stmt>. See 1.6.4(1). We really don't want to through those away. For example, we do want to allow call statements to have statement numbers and to follow source form statement rules. I kept the alt-return constraint in obs font like the original. I could have sworn that we decided a procedure pointer was a procedure, this making "procedure or procedure pointer" in the 1st constraint on procedure-designator repetitive, but I entered it as specified. paper 01-214r1 with the following changes [89:38] Consulting with /data, they agred that a better edit here was to move line [89:42] to [80:37+]. Did that. [401:8] I started to add an article to make this item like all the others in the list, but decided it was better to delete all the other artcles except for the first. paper 01-215r1 with the following changes [168:35+] Strike the "Note that". [186:41] "the end-of-file" -> "an end-of-file" paper 01-216 first edit only (deletion of the J3 note) as is paper 01-217r1 section 3 as is paper 01-218r2 with the following changes Used bnf for "SELECT TYPE statement" in the first edit. (It seemed appropriate to use bnf in the bnf constraints). paper 01-223r2 with the following changes Also deleted the sentence at [196:13-15]. (referred to the now non-existant io_modes argument.) paper 01-225r2 part 4 with the following changes Change punctuation of the "see table 13.x" clause. paper 01-226r1 with the following changes Also deleted [255:10], after consultation with /data to confirm that the deletions should also have included this line. paper 01-227r1 as is paper 01-228 with the following change The note was on page 341 instead of 402. paper 01-229 part 4 with the following changes [32:44+] I think the wording of the "if" phrase of this note (4.6 in 01-007r2) pretty abysmal. True, this is just copied from another place in the previous draft, but it was bad there also. I've entered this as is, but I don't like it. I'd propose to delete the "if" phrase. It makes it sound like the function can decide during execution whether it is allocatable or not. I think the reason for the phrase was probably to avoid the cases where allocatable function results return as unallocated or pointer function results return as disassociated. I think the attempt to avoid those cases causes more confusion than it solves. I'd say that one could still claim that in some sense the type parameters are still determined by execution of the function; they are just determined to still be deferred. If people don't buy that as sufficient waffle to allow omitting the "if" condition, and if there is no better fix, then I'd propose just deleting the note. As is, I think it does more harm than good. But I've not done this, and it doesn't come up to the level that I feel a J3 note is merited. If nobody reads this, I guess it will just get dropped (unless someone has a similar comment during integration). [137:15-138:37] "" -> "" many times. We no longer have plain as a bnf term, which is good because people kept confusing the bnf term with the non-bnf "target" and they were not the same. Looks like all the cases do refer to data pointers (all but one of them are in the section on adta pointer assignment). And removed all the "the"s from before "". Now that it is instead of just , the "the" doesn't cause quite as much confusion, but might as well still be consistent. Some (3) had it; some didn't. Likewise, removed "the" before "", which was also inconsistent. Same for proc-pointer stuff. paper 01-230r1 as is (the r1 has only one edit - at 345:31) paper 01-233r1 with the following changes Simillar change at 222:18 paper 01-234r1 as is paper 01-235r1 as is paper 01-236 with the following changes We have a bnf term for "an END statement in a main program". Used it to shorten the first sentence on the 15:22 edit. See similar (and probably redundant, but we'll ignore that for now) words in 11.1.1. paper 01-237r1 as is paper 01-238 as is paper 01-239 with the following changes [252:27-30] Entered as specified with no checking. I don't have the time to track down whether this is indeed redundant or contradictory. I'd be a lot more confident of the truth of that claim if the authors could at least specify whether it was redundant or contradictory (or, I suppose, both, which would imply that it is redundant with some material and contradictory with other, in turn implying that we still have a contradiction after deleting this). I'd be most confident if the redundant or contradictory material were actually cited. Oh well; J3 passed this, so I'll enter it. If the rest of J3 doesn't have time to verify it, neither do I. I can't prove it's wrong. I don't even have any basis for suspecting it to be wrong - I just find the cited justification "unusual" in its degree of waffle (in not even being able to decide between contradictory vs redundant). [252:31-32] I guess this just illustrates that different people find different things confusing. I found the original clear and this confusing. Took me 10 minutes to figure out that this really was equivalent. Guess I'm slow. Yes, it can be deduced, but I kept having to deduce it. Entered as specified. [252:36] I'm slightly concerned that without the bnf, this might be interpreted to mean any procedure entity anywhere, rather than just one named by a in this statement. Though I suppose one could say the same thing about the original with the bnf; it isn't really introduced by this change. The change just makes me notice it. Entered as specified. paper 01-241 with the following changes After consultation with /data, undid all the edits on pages 119 and 120. These requirements are already covered by the more general conditions at 119:33-34 and 121:25-26. paper 01-242 as is paper 01-243r1 as is paper 01-244 with the following changes I added all these sentences to the existing paras instead of making them separate paras. paper 01-245r2 with the following changes Used an alternate edit suggested by Kurt for 6:16. Reversed the edits for 347:43 and 348:2 (unless we really want to say that a component name may be used as a type parameter keyword, while a type parameter name may be used as a component keyword). paper 01-246r1 as is paper 01-247 with the following changes If I were sufficiently perverse, I might interpret the constraint added at 41:4+ to imply that it was fine to have both a PUBLIC and a PRIVATE access-spec (as they aren't the same) or to have multiple EXTENDS specs as long as they extended different parent types or had different initialization. But I'll leave those interpretations to someone else to consider. Entered as is. [43:20] Same change as [43:14] paper 01-249r1 as is (including the suggestion) paper 01-250 as is paper 01-251 with the following changes Omitted comma from first line of the 131:11-13 edit. (Don't use commas with 2-element lists unless necessary for clarity. In this case, writing the list with the (a)(b) syntax provides adequate clarity. I changed function to subroutine in the 136:36 edit. Changed "input-output" to "input/output" twice. Although we've debated several forms for this term, a hyphenated form wasn't one of them, and it appears nowhere in the standard. paper 01-252r1 with the following changes Omitted the period after "Argument(s)". "requirements of" -> "requirements on" "argument(s)" -> "arguments". There is no need for the ugly "(s)" construction here. It is quite normal to refer to the plural in cases where there might be only one. Indeed, we do that most of the time for the word "argumens". The "(s)" construct is used nowhere else in the standard. Nor do we typically use any of the other forms of explicit acknowledgement that the plural could include the singular here. Heck, we often say "arguments" in contexts where there might be none. Flipping open the standard to a likely place, it took me about 5 seconds to find a case in the second line of 12.4.1; it just says "arguments"; not "arguments or argument, if any,". I left the "(s)" in the phrase that names the "Argument(s)" paragraphs because it is referring to paragraph names, which we do use both forms of (perhaps we shouldn't), but I don't see any reason to use the "(s)" with the ordinary word "arguments". Pluralize the first inserted sentence. The preceding sentence was in the plural, and the newly inserted subsequent sentence is also plural. Keeping this one singular without suitable transition makes it sound like there is only one such paragraph instead of one per intrinsic. Delete "of the invocation". This is just extra words that add nothing. It is fine to refer to requirements on the actual arguments of the procedure. We do, I see use the term "actual arguments of the invocation" one other place (in annex B.2.5), but I still think it wordy. Numbered all constraints and changed their paragraph format. Changed "their associated constraints" -> "constraints" twice in 1.5. This is to make sure all constraints are covered, including those not directly associated with a syntax rule, a possibility we now provide for. In the process, ended up giving R numbers to the assumed syntax rules of 1.6.3. That was convenient at the time and I didn't see any reason not to. If J3 prefers not to do this, that part can be undone. Added a subclause 1.6.3 describing constraints. This could alternatively be done as one of the numbered items in 6.6.2, but I concluded it seemed slightly better to make it a separate subclause. The words added are all unreviewed - consider them as a first draft. Clauses 4, 5, and 12 have 84, 93, and 84 constraints, respectively. If this grows much, we'll need to go to 3 digits (which is doable) or do something else. For now, it is ok. Made a quick pass with my guess at the appropriate syntax rule to which each constraint is attached (or none in some cases). Again, consider this as a rough draft. It was pretty hurried, plus others might disagree with me on some cases. Not all of the choices were obvious. For example, note that I associated C404 with R406, but the simillarly phrased C405 with R405. (Partly because C405 refers to concepts that are undefined without knowing what type this is a kind-param for, and partly because C409 seems to be the equivalent of C405 for reals, but I see no separate equivalent of C404 - if C404 doesn't apply to reals, then we have problems with, among other things, selected_real_kind). There are other examples where it was not at all obvious, making it evident to me that some annotation like this is overdue. I'm also sure I was inconsistent on some matters. I did not do any moving around of constraints, though it seemed likely to be appropriate for some. In some cases, constraints should probably be moved to right after the rule they apply to. In other cases, constraints not associated with specific rules might now be better placed near the discussion of the issue in text. (This seems particularly relevant in cases where the constraint is just the statically checkable subset of a more general text requirement - the constraint might then be well placed right after the requirement). I'll leave this for subsequent J3 work. Some notes on this. A bunch of these should probably be unresolved issues, but I didn't make them so. SOme of these don't even have anything to do with the constraint numbering, but were just unrelated thoughts. The associations of several of the constraints in 4.5.1 are quite arguable. Consider my draft as awfully rough here. I think that in several cases, matters might be improved by minor rewording of some of the constraints. For example, some of the constraints might be best associated with lower-level syntax terms, but make reference to context outside of that term - in such cases, the context needs to be mentioned explicitly as a condition of the constraint. Conversely, some constraints on high-level syntax terms refer to things that appear multiple levels down in the syntax tree rather than directly in the high-level bnf - in such cases, the constraint needs to give a hint as to how the things referred to relate to the associated bnf rule. This kind of wording improvement might help elsewhere also - section 4.5.1 was just where I first noticed it as being pretty badly needed. I made no attempt to actually do such wording changes. For one particularly egregious case C419 pretty much says that if BIND(C) appears, then BIND(C) shall appear; it really needs to be more specific about context (two different contexts, both within derived type definitions, are meant). C441 and C461 seem like good candidates for putting in subclause 4.5.1.6 instead of associating with individual bnf rules (and then we'd only need to say it once). Several of the constraints in 5.1.0 might be good candidates for disassociating from the bnf. Many of these are really constraints on combinations of attributes that are allowed, regardless of what statements are used to specify the attributes. If these constraints were stated that way instead of as constraints on the syntax, the weasel words in 5.2.0 wouldn't seem quite so weasely. But as many of them are currently worded, they don't make much sense without more context (adding a phrase like "for an entity" would be enough for many of them). C507, on the other hand is phrased broadly enough that it pretty explicitly is not tied to particular bnf (and that's good). In some cases, the explicit bnf rule association makes some of the words superfluous. For example, in C501, the explicit association with R502 makes the "In a " superfluous. There are other cases also. I did nothing to fix these. C577 seems anomalous to me. I don't know why we feel it necessary to call this out as a constraint when there are a whole bunch of other things that a namelist group name also can't be the same as, and there are a whole bunch of other statements that can't use a name made accessible by use association. It struck me because in going through all the constraints in section 5, I came to this one and hadn't before seen anything similar. Looks to me like C634 is redundant with C621, provided that C621 is indeed associated with R628 as I have indicated. Should not named-constant (R307) be constrained to be a constant? I suspect that "data pointer" would now be better wording than "nonprocedure pointer" in C621 and C634. I gave the bnf rule for dtv-type-spec a number (R920) so that it could be referenced. I'm aware that this rule is not used elsewhere in the bnf, but I don't think that precludes it having a number. I waffled about where to put constraints on various xyz-list terms when the constraint really applied to the -list instead of to individual items. (Constraints like that some items in the list precluded others, or that a list had to include some item). The constraints logically go on the xyz-list, but we use the implied syntax rule for that. I could put them where the xyz-list is used, but sometimes that is in more than one place (as for io-control-list). Ended up deciding to put the constraints on the elements, though this might mean that minor rewording (which I didn't do) is appropriate; possibly adding something like "in an ". I did some lists like this differently (prior to c09, where the multiple use really hit) and have not gone back to make this all consistent. Perhaps will do so later if have time; or perhaps just let it do for a first draft. In either case, this para is to record my thoughts on the question. C1007 is a fairly rare case where one constraint refers to multiple rules. (It's basically 5 constraints rolled into 1). Although that does "work" with the current syntax, I didn't want it to become a problem with possible different ones. "Cheated" by associating it with the single bnf term one level higher. I find it confusing that C1218 refers to bind-spec without giving a hint as to where one might be. I suppose that perhaps the reader is supposed to remember from C1217 that bind-specs can be found in language-binding-specs. This presumes that the reader is quicker on the uptake than I was. I tried grep to find if there really was such a thing as bind-spec; only then did I notice the reference in C1217. Yes, I know it's on the line above, but I figure that each constraint should stand alone a little better. The xref to R1201 right before C1234 is a Frameo. It obviously should be to R1221. Oh !@#$ do I hate this class of Frameo. I just noticed that it has hit about 50% of all the constraint xrefs. This is going to cost me most of a day. Grumble. To fix this class, you can't even just correct the xref or Frame will trash it again when you aren't looking. You have to find and delete the bad xref tag that Frame has made on the thing you are trying to xref. Then you have to delete and recreate every reference to it. Boy, am I getting sick of Frame. The above mentioned sentence with the R1221 xref (formerly R1201) now seems redundant with the xref in the constraint, but I left it here in case someone thinks it useful as a leadin (I don't, but...). I actually think the best solution may be to not associate these constraints with particular distant syntax rules at all; I think the only reason for calling out the syntax rule here was the convention (now gone) that every constraint had to be attached to a syntax rule. But associating with R1221 does "work", if J3 wants to leave it that way. C1260 seems to me needlessly duplicative of C1101. Syntactically, the only place other than a subprogram that a return statement could potentially appear is a main program, which C1101 rules out. I also find it oddly wordy phrasing to say "function or subroutine subprogram" instead of just "subprogram". (Check the glossary entry for "subprogram"). I did not list any associated syntax rule for the constraints in 12.6. They all seem explicit enough about their context to stand as is (presumably by design). If we did associate them with specific rules, many of them would probably need two associated rules (one for subroutines and one for functions). I also think that the third sentence in 12.6 (the one citing the bnf rules for subprograms) is unnecessary now that we don't insist that constraints have to have associated bnf rules. I think this sentence was just a way to tokenly meet that convention - it doesn't actually add any content to what the constraints say themselves. Same comments for 12.7 as for 12.6, except that wording in 12.7 could use improvement. (See the unresolved issue 338).