J3/97-206 Date: 1 Aug 1997 To: J3 From: R. Maine Subject: Status of f2k edits A version of this was sent out earlier on the email list. Two of the items in here seem worth highlighting. First, there is the technical change to pointer lower bounds for zero-sized arrays. I have made that change in entering the edits (contrary to what I said in the paper discussing the details - I wrote that one earlier and forgot to update that aspect before sending it out as a paper.) Second, the proposed change to case (ii) of maxval and minval. I have not made this change, but am leaning towrds doing so, so let me know if there is objection. I have now entered all of the approved edits for f2k. These come from papers 96-154, 97-156R1, 97-160R1, and 97-161R2. I have not assigned the new document a number or put in on my server because the edits are just in a few isolated places. I felt obligated to put out 97-007 as the x3j3 internal working version of the f95 standard - people will undoubtedly want that for interpretation work. The changes for f2k are as yet small enough that its silly to print out and bring to the meeting both 97-007 and the newer document. I'll accept the next round of edits against either 96-007r1 or 97-007 (the differences there are so small that you'd have to work really hard to make an edit that was different between these two - if you manage such a trick, I'll cope). I do *NOT*, however, want edits against the non-numbered and non-available new document (and that's why its not available). Although the places edited are very localized, there was resulting rule renumbering from it. Even if I asked for edits only against this new document, I'm almost certain that some people wouldn't bother reprinting anyway, and this could cause confusion about rule number references. Since we are starting on a new standard, it seems an appropriate time to (re)raise some questions of how things will work. I have two general issues that I'd like some feedback on. 1. You'll notice (below and/or in the revised pages when I put them together) that I've been moderately "agressive" in applying editorial discretion in entering these edits. That is, I've done a fair amount of rewording of the approved edits - more than I usually tended to do when we were working on f95. Some of the "editorial" discretion was even applied to fixing technical issues (see the pointer lower bounds stuff). I dunno why I always see a lot more to rework after I actually sit down to enter the edits, even when I thought I carefully studied the edits before they passed - but it always seems to happen. Of course, J3 can always object to specific cases of my rewording (so tell me if you object to any of the ones below). The general question is whether you want me to back off and do less rewording in the first place, sticking more closely to whatever is passed. I have heard at least some informal comments from people that I interpreted as them hoping I'd "just do it." If you don't like me doing this level of editing, now's a good time to speak up (so I don't waste so much of my time doing it and J3's time telling me to undo it). 2. Somewhat related question, really. In the past, I've usually tried to report every comma that I entered differently from the edits as passed. There were a few exceptions where it was just to hard to detail the changes and I just said that there was significant rewriting of xxx and to see the draft for the result. If I'm going to be doing moderate editing, along the lines of what I did for these papers, then it can sometimes be as much (or even more) work to describe the edits in detail as to actually do them. I'd be tempted to lower the level of detail given in my editing reports. That is just to state things like that I did moderate rewording in area xxx for reason yyy instead off trying to detail exactly how I reworded it. I would certainly need to give enough detail for people to find the parts that I reworded, but my reports would emphasise more where the rewording was and why I did it (in cases where there were non-trivial reasons), instead of what the changes were. I get the feeling that a lot of my detailed reports aren't always read that carefully anyway. And its more important for people to be reviewing the actual draft standard document. This might actually help me highlight the more significant issues that I find, instead of burying them in between changed commas. (Speaking of which, there are some technical issues and some specific questions below - don't miss them - perhaps well illustrates my point). Of course, the option in the "other direction" is that I shouldn't make any changes at all, even to spelling and grammar, so there won't ever be anything to detail. But I think you were looking for more than a typist. (I'm pretty poor as typists go, though its true that the selection among those willing to work for this salary is a bit limited, even after my recent raise from -$600 to $0 per year :-)). End of general questions. Specific editing details follow. 96-154 - pointer lower bounds Simplified wording of the new constraint by changing "specified shall be equal to" -> "shall equal" The "specified" doesn't seem to add anything in this context, and the active voice is more succinct. Technical change - added "If is specified, " at the beginning of the constraint. Otherwise, it might imply that the bounds-spec-list always had to be specified for arrays. Hmm, that brings to mind another technical question. Technical change - added another constraint (preceding the above-mentioned one): "A is allowed only if is an array." I don't believe that anything else otherwise prohibits P() => T for scalars. (I suppose we could allow it, but I doubt that was intended). Substantial editorial change in the description of how the bounds are specified. Most significantly, moved the whole description into section 7.5.2, where it really belongs as part of the description of the pointer assignment statement. If we didn't move it, there should at least be an xref in section 7.5.2. I've had trouble finding this material before. I made item (2) on page 55 just a single sentence referencing 7.5.2 for details. I used the first sentence from the paper 96-154, with the xref added. Note that this is consistent with how item (1) in the same list is done. Item (1) has a single sentence referencing 6.3.1 for details. Also in that description, re-ordered the sentences to follow the same structure as used in 5.1.2.4 on assumed shape arrays. Namely, the sentences about extent and upper bounds come first, followed by the definition of the lower bounds. The paper 96-154 version has the upper bound discussion between the 2 cases of lower bounds, possibly making it confusing whether it applies to both lower bound cases or only one. A few other small editorial changes to go better with being in section 7.5.2 (like using bnf terms, since it is right below the bnf definition). Technical change - removed the special case for zero extents. See separate paper discussing that. This change provisional on x3j3 agreement. (Well, ok, so are all of the changes, but this one seems to me more likely to be questionable). That's enough changes to be hard to picture, so here's the resulting para that I put in 7.5.2. (Hey, cut and paste from Frame to xemacs works - neat. Loses the fonts and equations, but does get the words). The extent of a dimension of is the extent of the corresponding dimension of . If the lower bound value is d and the extent of the corresponding dimension of is s, then the value of the upper bound is s+d-1. If a is present, it specifies the lower bounds; otherwise, the lower bound of each dimension is the result of the intrinsic function LBOUND (13.14.53) applied to the corresponding dimension of . 97-156R1 - min/max for char args. In the first sentence of the result characteristics for max and min, added "The", "of the result" and "those of". Added a comma in the last sentence of case (i) and (ii) for maxval and minval. Re-ordered the phrases of case (i) and case (iii) in maxval and minval so that the distinguishing characteristic of the case appears first. (It already does in case (ii), and it did in case (i) in f95). Otherwise, it might appear at first glance like case (i) covers the non-zero sized arrays. Instead, case (i) covers both zero and non-zero size; the distinguishing factor is which arguments are present. The form relevant to each case then being clearer, we can then just say "the result" instead of repeatedly spelling out the whole form in case (i) and (ii). (Case (iii) already did this, perhaps because the form got long enough to exceed someone else's tolerance for the needless repetition). I had minor reservations in case (ii) about referring to "true elements" of MASK, instead of something about elements with the value .TRUE. (all the elements are "true elements", as opposed perhaps to virtual elements), but I decided not to do anything about it because it would complicate the sentence structure quite a bit, it was that way in f90 and f95, we are probably equally careless with the same kind of wording elsewhere, and I doubt anyone will actually be confused. I was very tempted to (but did not yet) majorly simplify case (ii) of maxval by replacing it with The result of MAXVAL(ARRAY, MASK) is equal to that of MAXVAL( PACK(ARRAY, MASK)). and correspondingly for minval. Note that this completely replaces 9-10 lines (for each intrinsic) having multiple conditions. Probably the only reason I didn't make the change is that it didn't occur to me until after I got the long version typed in, and I don't want to have to type in in twice if my proposed change is rejected. Soliciting inputs on this. 97-160R1 - system clock. Inserted the example as normative text, in the same style as all other examples in section 13.14. There is not a single example in the entire intrinsics section that is in a shaded note. Removed the "1,193,180/65,536 or" from the example; it is completely irrelevant and adds no content relevant to the Fortran standard...and the extra "or" made the sentence structure a bit hard to follow in conjunction with the following change. Changed the "Assume that" back to "If" (and correspondingly change ". At" to ", at") as in the original example. There is no obvious reason for the change in style, particularly since the original style seems preferable. The use of "assume" in the imperative in normative text might possibly be misconstrued as a requirement on the compiler - in this case that the compiler is required to assume this particular count rate. A bit far-fetched perhaps, but the conditional form using "if" avoids the question. I cannot find "assume" used in the imperative anywhere else in normative text (and only once in a note). Changed back to commas instead of semicolons to separate the 3 values in the last 2 lines of the example; and added the period back onto the end of the sentence. Again, these were changed from the f90/95 version for no obvious reason (and the original seems better). This whole paper excellently illustrates a basic point of preparing edits. Please do *NOT* phrase edits as replacing a whole section when the actual changes are much smaller. If there are extensive changes, so that it is hard to describe or follow the actual edits, then yes, replacing the whole section is probably reasonable. But please use at least some judgement in the matter. That was clearly not the case for this paper. There was a 1-word deletion in the 6-line description of COUNT. For that trivial edit, I'm supposed to retype the whole thing, introducing new typos in parts allegedly unchanged? I think not. What I did instead was visually "diff" the original with the new version to find the 1-word difference. My visual diff skills aren't that good; I'll miss things. (And when I'm having to do things that I'm not good at, I get grouchy and write things like this). The fact that I was having to do a visual diff is what drew my attention to several of the changes that appeared unintentional. 97-161R2 - lower case. Changed the second sentence from plural to singular as preferred style. (Yes, I know the f90/95 text was plural here, but might as well fix it anyway). Fixed the example to be consistent with style used elsewhere. Namely, we tag them as "notes" and don't start them with "Example:" Used colon instead of period at the end of the lead-in sentence in the note.