J3/99-102 Date: 13 Jan 1999 To: J3 From: Richard Maine Subject: Edits incorporated in 99-007 This paper describes the changes in J3/99-007 relative to the previous f2k draft, J3/98-007R3. All page/line references are to J3/98-007R3 unless otherwise noted. All of the changes mentioned in this paper have been done in the draft. Although there may be some questions raised below, they do not necessarily require action in my opinion. Those issues which I believe to require action have been put into a separate paper of unresolved issues for addition to the 011 document. This was done to help highlight and track the items requiring action. Ths change bars in 99-007 are relative to 98-007r3 misc edits [7:4-5] Changed citations of the floatting point standard to refer to IEC 60559 (1989-01) per email from Miles. [63:9] "Constraint:" to obs font, just like all its text. [63:19,22] Definition of "assumed character length parameter". Deleted the definition. Added reference to 4.2. See further discussion under [63:18] of 98-208r2 changes. [368:15-16] Fixed the glossary entry for "type parameter" so that it doesn't lie. (It said type parameters were only for intrinsic types). [368:16-17] Deleted the glossary entry for "type parameter values". We have an entry for "type parameter". The "type parameter values" entry adds nothing that is not completely trivial and obvious (the values of the type parameters). Plus it repeats the error of restricting itself to intrinsic types. Fixed the index entry for "VOLATILE statement". Fixed the example in date_and_time to address Dick Weaver's objection that... "I was in Geneva on that date, at that time, and used my pentium laptop to call date_and_time. The value assigned was not as given in the example, but was, in fact, local time for San Francisco at that instant." 10.5.1.1 Added "as in" before the xref to R408-410 to address Van's objection that these R items define constants, not digits. Nuked section 7.1.6 heading and the material of 7.1.6.0, promoting all the subsections up a level. The section title of 7.1.6 had nothing observable to do with any of the subsections. The one sentence of content in 7.1.6.0 vapidly says something that is said many other places and is out of place here. The example is simillarly lacking in content. The whole 7.1.6.0 looks like someone felt that there should be some content to go in the section, so they wrote something; might as well just have said "Hello, Mom." Besides which, the subsections are important, and raising them up a level hides them a little less. Paper 98-208r2, explicitly typed allocs, with the following changes [30:28] This edit failed to delete the requirement that non-kind parameters be specified by specification expressions. I revised it to fix that. I also added and modified some words for both kind and non-kind type parameters to clarify that the business about using them in specification and initialization expressions applies within derived type definitions. [30:33+] There are probably exceptions (didn't bother to check), but as a general rule, there should not be a subsection unless are two or more subsections at the same level. I didn't say that well. More specifically, we shouldn't have a 4.2.1 unless there is also a 4.2.2. The proposed 4.2.1 is short enough, at one modest-sized paragraph, that it doesn't appear to merit an exception to this principle. We could "solve" this by also making separate subsections for kind and non-kind parameters, but I think it better to just avoid that level of subsectioning here. Section 4.2 is pretty short, even with the new paragraph. The first sentence of [30:33+] needs work. The "for which" phrase appears to modify "entity" instead of "parameter". Redone. It also strikes me as anomalous that we define "deferred type parameters" here, but "assumed type parameters" somewhere else. The para above this mentions deferred and assumed in the same context. It then seems odd to see one explained here, but not the other. Not sure whether its best to add/move stuff about assumed to here or to move this stuff about deferred elsewhere. Hmm. I put it in 4.3 instead of 4.2. It seems a bit more appropriate there. Not sure whether that is optimal, but I guess it will do. At least 4.3 has something to do with object declarations, unlike 4.2. (But see unresolved issue 81) Rewrote the para a fair amount. Deleted the bit about dummy args as it seems out of place here and is covered in a separate edit in section 12. [38:11-12] This edit misses some of the flavor of the original. The whole point was just to reiterate the statement that there is no default value for a derived type parameter; the value has to be specified somewhere. This isn't the place to go into details about what kinds of specifications are allowed for what kind of parameters. Look at the parallel sections for intrinsic types. This is intended to be parallel with the stuff about default parameter values in those sections. I'd also argue that deferred parameters are specified explicitly - just not in the type declaration, but that's perhaps an arguable point (and even more so for assumed). I tried a rewording with substantial simplification, trying to avoid all these side points and concentrate on the main one. Since the whole clause is just restating the first clause of the sentence in different words for emphasis, we could just omit it; that would be preferrable to making it too complicated. I just changed "specify" to "specify, assume, or defer". [54:2-3] The constraint is now redundant with the one above it. It was previously needed because of the specification expression bit. Now that that bit is gone, this constraint is a direct and trivial deduction from the preceeding one. (A type param value may in general be an expression, asterisk, or colon. Kind type param values may only be expressions. Therefore an asterisk or colon may only be used for type params that are not kind type params). So I deleted it. [54:5+] I didn't like the bit about "the declared entity". It lacks a referent and is particularly confusing in cases where the derived type specifier is not in a type declaration...in fact its probably even wrong in that context. Consider (I think I recall the syntax we passed - if not the idea still applies to the correct syntax): character(:), allocatable :: c ... allocate (character(:) :: c) The only entity that is a candidate for "the declared entity" in the allocate statement is "c", which is allocatable. But I'm quite sure you didn't mean this statement to apply in that context. I reworded this using "in the declaration of" wording simillar to that of the preceding constraint. (And I see that I'm dropping in my mode of writing a longer paper than the original just in order to explain the problems I have with the original. Puts me in a grumpy mood. Bah, humbug. Well, perhaps its just my wordiness). [56:9+] Strange place for this edit. It has nothing obvious to do with derived type constructors, which this section is on. I put it at [54:13+], where it fits nicely right after the corresponding para on assumed parameters. Also, reworded it. I have trouble with "execution of argument association", which is how I read the words written. Plus we have an "Irish Bull" in "a derived type that is specified by a colon" (it is supposed to be the parameter that is specified by a colon). ...later. Reworded it further by deleting most of it, leaving just a short xref to 4.2. The general topic of deferred type parameters needs to be someplace more general like in 4.2, which applies to both intrinsic and derived types. Otherwise, we end up saying the same thing twice - once for character and once for derived types. [59:18] The J3 note on CLASS in restricted-type-spec is numbered as unresolved issue 71. I also added a sentence questioning whether restricted-type-spec was the best term here (since it isn't a subset of type-spec). I added an index entry for restricted-type-spec pointing to its bnf. I certainly hope that the restriction on type-param-values in restricted-type-spec is intended to be a constraint. The equivalent restriction used to be a constraint. I redid this one as such. While on the subject, fixed the Irish Bull in "a restricted-type-spec that is an integer expression". It is presumably supposed to be the type-param-value that is an integer expression. (You are really prone to those Irish Bulls, Van). Also, I made the restriction apply to char-len-param-value as well as type-param-value because character length doesn't use the bnf term type-param-value). Hmm. Perhaps it should, but I'll make that question an unresolved issue. And I added a simillar constraint on char-len-param-value to entity-decl, since that wasn't covered by the constraint on restricted-expr. I assume that the sentence after "Note:" is supposed to be a shaded note. The instructions doesn't make this clear, but the material certainly seems appropriate for a note. I'll assume that's what "Note:" was intended to convey. Made the two clauses of the note agree in number (choose singular). Changed "array constructor" to "constrcutor" to cover both array constructors and derived type constructors. Removed the misleading "also". (Type-spec is used ONLY in constructors and allocate statements, not everywhere that restricted-type-spec could be used and ALSO in the other places). [63:8+] I put this at [63:6+] so as to keep it out of the middle of all the obsolete stuff. Also reworded much like [54:5+]. [63:11] "type-spec" -> "restricted-type-spec". Likewise at [40:7], [40:10], [72:30], [82:2], [248:20], [250:5] Damnit, these are not subtle! Grep shows only 23 cases of the string type-spec in the document, and many of those are in derived-type-spec. Weren't they all checked? Am I the only one that actually checks this kind of thing? Wouldn't it occur to people that if one changes the definition of a basic syntax term it might be a good idea to check those places where it is used? If I was that sloppy about coding, I'd never get anything to work. I suppose since this is just a standard its ok to be sloppy? If this keeps up, you are going to need a new editor. These are not wording fixups. These are technical errors. I won't allow my name to be associated with something done this sloppily, and I don't have time to do the homework for everyone else. [63:18+] Why do we need to define a term "deferred character length parameter", complete with bold face, which we then use absolutely nowhere? Hmm... Perhaps because we were following the style of the definition of "assumed character length parameter", which is similarly defined here but then used nowhere. A grep of the entire document for "assumed char" reveals 3 cases in Annex B, one in c12, and this one. (plus a TOC entry for Annex B and an index eentry for this one). None of the other cases of "assumed char" actually include the word "parameter" at all. Ok, so I fixed both this and the "assumed char len" one. I have the same kind of wording problems (perhaps because it uses the same kind of words) here as I did in other places with the business about executing an argument association. I wimped out by removing those words from here entirely. Reference 4.2, which should cover it all. That way we only have to get the words reasonable once. Besides which, its the right way to do it; we are not trying to say anything special about deferred character length; we want it to act just the same as any other deferred type parameter. So xref the general discussion instead of trying to repeat it and perhaps end up with an unintentional difference. [68:40], [69:1-2] The business about an ALLOCATE statement does not belong here. Putting it here just misleads. You are required to specify the type and type parameters in a type declaration or component def statement. Period. Now that specification may say that non-kind parameters are deferred, but you still have to specify that much. The wording proposed implies that you might get by without specifying the type and type parameters at all until the ALLOCATE statement. Plus, of course, if you are trying to cover all the ways that a deferred type parameter might set, you missed several. It could be assumed if this is a dummy arg. For a pointer, it might get set in a pointer assignment. But this is certainly the wrong place to discuss all that in detail because that has nothing to do with arrayness. This is, after all, the subsection on deferred shape arrays in the section on the dimension attribute. If that material ends up going here, then is isn't going to apply to scalars. I added the sentences about possibly being deferred, but not the edit about the ALLOCATE statement. [96:23+] A type-name doesn't have a type. Reworded. Other changes. [96:25+] Rewrote the "when" bit to avoid time dependence. Much of this has nothing to do with time. The only time-relevant part is the agreement of values, which has other problems anyway (see unresolved issue 74). A bunch of other things also fixed, namely wording that better acknowledges that a single type-spec applies to every allocate-object (and the different allocate-objects might have different deferred parameters). I found it disconcerting to read all about the type-spec specifying type parameters and then, as though it were unrelated, to read about the type-spec specifying the dynamic type of polymorphic objects. Therefore, I added an introductory sentence about type-spec, mentioning both things in place of the introductory sentence that formerly mentioned only the type parameters. It then seemed to work better to put the short part about specifying dynamic types before the stuff about type parameters. Reworded the case about the type being omitted to say it creates an object with a dynamic type the same as its declared type; I didn't think the proposed wording was quite explicit enough about this. (It just said "creates an object with the declared type of the object". It didn't explicitly say anything about dynamic type (although the sentence it is replacing did). Oh yes, and I don't think we actually need an xref for every occurance of the word polymorphic. We had an xref a few lines earlier in a constraint, so I left it out of this sentence. Putting xrefs like this on the first occurance in a section seems adequate. Moved the para about subsequent definition/undefinition up to be part of an earlier para. And simplified its wording to follow the style of the same statement a few paras later about bounds. (Looks like part of the wording was copied from there; I copied more.) Just "in the type parameter expressions" instead of "within any expression that provides a value for a deferred type parameter." Moved the para about allocate-shape-spec-list down with the other material relating to bounds. [96:34] Did the change to "When". (Its just an editorial fix, but a good one). Did not change "array" to "deferred-shape array". It is also true for non-deferred shape ones. We require, (later in the same para) that the bounds for the non-deferred shape case agree with the declared bounds, but that doesn't make this statement false. [130:5+] Inserted this at [129:43+] near other stuff on types, instead of after the unrelated stuff on bounds. Also changed "nonkind parameters" to "type parameters". We otherwise don't have enough context to make it clear that we are talking about type parameters. And it isn't important to restrict it to nonkind ones, since we can't have deferred kind type parameters. [230:18] While on the subject, also change "character length" to "type parameter". It is clearly appropriate for all type parameters. Looks like an edit missed for pdts. [231:22] Made a separate list item to fixed the grammar so that it doesn't expand to "a dummy argument that is has a deferred type parameter." Proposed edit had just added "has a deferred type parameter" to a list preceeded by "is", thus the "is has". [242:42+] I think this goes better around [240:46+] near other discussion of type parameters, instead of after the material on INTENT. Also, it seems overkill to go to all the trouble to define the term "deferred-parameter entity", complete with a glossary entry, in order to use it in only this one sentence. I don't think its a particularly evocative term anyway in that it doesn't use the term "type parameter"; there are plenty of other kinds of parameters for the reader to confuse this with. But since we only use it one place, I can just say what we mean there without needing to invent a term. We didn't seem to need this term to say the same thing at [130:5+]. Changed. And omitted the definition from [30:33+] and from the glossary. And made the 2 paragraphs one. Need this in order to tie the former 2nd para to the conditions mentioned in the first para; [361:44+] The proposed glossary entry for deferred type parameter is backwards in that it defines just the syntax used to specify a deferred type parameter, whichout actually defining what it means for a type parameter to be deferred. Rewrote along the lines of the definition in the normative text (as revised). Paper 98-211r2, stream i/o, with the following changes. The J3 note on spelling I/O is numbered as unresolved issue 67. "in a file" -> "for a file" several places. In the first para of the "file storage units" section, change "unformatted direct access" to "unformatted files". (Unformatted sequential files also have record lengths and they are measured in the same units as unformatted direct access files). In the next para ", which" -> "; this number". (The "which" was dangling in that its antecedant was supposed to be "number" instead of "units"). The J3 note on unlimitted length formatted records is numbered as unresolved issue 68. The J3 note on effective items is numbered as unresolved issue 69. The J3 note on DTIO wording assumes formatted is numbered as unresolved issue 70. "last" -> "highest-numbered" in the POS= specifier in INQUIRE. Instead of adding the J3 note about how the terminal point of a stream file gets extended, I resolved it by adding a sentence and a note in section 9.2.3.3 (formerly 9.2.1.3.3) on file position after data transfer. Several spelling errors/typos. Paper 98-213r4, status error msgs, with the following changes Deleted a comma in the first edit. (Add one in the 3rd to make up. :-)) Use the same syntax conventions for optional arguments as we do for other intrinsics. Paper 98-224, y2k. Paper 98-226r1, select type fixes, with the following changes. issue 54. The last sentence of the edit duplicates the content of the first constraint after R818 (type-guard-stmt) a few lines earlier. There are arguments for either place, but not both. I flipped a figurative coin and deleted the one after type-guard-stmt, influenced mostly by keeping the wording as simillar as practical for the various named constructs. In the process of checking for wording simillarities, I was struck by the half-random switching between the terminology like "that is identified by an xxx-name" vs "that specifies an xxx-name". I changed all cases of this to the "specifies" form in the sections on the block IF, block DO, select CASE, and select TYPE constructs in section 8. Either form seemed ok, and "specifies" is both slightly shorter and no less precise. issue 55 Changed "expression" to "type selector" several times in the 2nd para of 8.1.4.2. (Several such changes mentioned in the paper, but these appeared to be missed). issue 56 The last sentence of the edit at [327:43-44] has more to do with scoping issues than with the association per se. Simillar issues for other construct entities are discussed in 14.1.3. Therefore, I moved this material to 14.1.3. While on the subject, reworded it to be identical in style to the same para about FORALL (in fact, I actually just made a copy of that para and edited it). We could possibly say this in both places if this is felt necessary, but I certainly notice its absence from 14.1.3 if it isn't there. Italicized "name" and "construct" in the new glossary entry for "associate name." And while checking on that, added SELECT TYPE to the glossary entry for "construct". No, I didn't recheck the whole glossary, but that one jumped out at me. In the edit at [335:40] "variable in a" -> "variable that is a". You want the case where the variable *IS* the type selector, not where the variable appears in an expr that is the type selector. issue 58 Add "The" to avoid beginning constraint with bnf term. Significant wording rework on the numbered list describing the matching algorithm, as follows. Avoid referring to *THE* (singular) statement that matches. Several may match; we are selecting the best match. Also, simplify the wording by using "otherwise" instead of having each case explicitly restate the negative of all of the preceeding cases. (P.S. Yes, the "must" in (3) is intentional and should not be "shall". It states something that is inevitable, not something that is a requirement). "picks" -> "selects" in the note (because that is the term used in the normative text). The edits still explicitly said that a name is an object, which is not true (one of the many problems mentioned in issue 58). Fixed by changing "the associate name is a polymorphic object" to "the associate name is polymorphic" and some wording changes later in the sentence to fit. "type (both declared and dynamic)" -> "declared and dynamic types". ", and" -> "; it". issue 59 This material seems to belong more to 7.1.4 (Data type...) than to 7.1.1 (Form...). Moved there with substantial rewording, but more probably needed. While in the area, noticed that the last para of 7.1.4 doesn't well reflect pdts. Deleted it and just added "type parameters" twice in the first sentence of 7.1.4. In fact, it stood out rather strangely that the first sentencce of 7.1.4 largely echoed the section title except for the omission of mention of type parameters. Hmm. More substantially, several possibly polymorphic cases appear to have been overlooked. How about a polymorphic object in parens? How about an array constructor with polymorphic elements? I made a half-hearted attempt to fix this, but I doubt it is good enough. See unresolved issues. We don't normally have glossary entries that just say to look in the text for a definition. So I integrated the expression case into the definitions of declared and dynamic type in the glossary. Hmm. Looks like the appropriate term that covers data objects and expressions is "data entity", which is already defined. Used it. I didn't try to detail all the cases in which the declared and dynamic types of an expression might differ (partly because I'm not sure I'd get it all right and partly because it might be too complicated for a reasonable glossary entry). Added the xref to 7.1.4 in the usual glossary syntax. issue 60 A name is not a variable. A variable *HAS* a name, but the two are not synonymous (so to speak :-)). Fixed. Left rank in the list of properties. And added a comma. Paper 98-227r1, tbp fixes, with the following changes. Item 1.5 Italicized stuff as appropriate. Will people please pay some attention to the first para of annex A when doing annex A work? I wouldn't oppose getting rid of this italicization convention (seems a bit silly when half of the Annex appears to be italicized.), but if we are going to keep the rule, lets pay at least token attention to it instead of expecting me to fix everything up. Also the wording makes it sound as though only one procedure can be bound to a type, but I went on to other things instead of trying to fix this. Issue 35 I fixed the unbalanced brackets in the edit at 39:2-7. Let me know if I got it wrong. (Doesn't look like there was any point in making the type-bound-procedure-part optional because everything in it is already optional. On second thought, used a different fix. For increased parallelism with the other *-part syntax items in 2.1, moved the contains-stmt into the type-bound-procedure-part. This change has no substance - just parallism of expression. Left the "construct" in the "proc-binding-construct" that is part of the type-bound-procedure-part syntax. I assume its omission was accidental. Issue 36 Added a comma in both constraints. I left the "called" after "The first of these is" because I thought this helped make clear that this is a definition rather than a requirement. (Phrasing already implied that, but I thought the "called" made it more obvious). Also changed "of these" to "such dummy argument" to make sure that the antecedent was clear. (Again, it probably already was, but this made it more so). Issue 39 "case" -> "CASE" twice. And added a "those" for consistency. Issue 40 The proposed edits address most of the wording questions raised, but this material still is misplaced. It goes much better in 4.5.1.6 (accessibility). Indeed, there are words in 4.5.1.6 on the subject, but they express it quite differently, and the two versions don't play together well. The version in 4.5.1.5 just talks about the binding being public or private, without saying what conditions make it public or private. In particular, it doesn't mention what happens if the access attribute is not specified in the binding. Section 4.5.1.6 does cover the access attribute being omitted, but then it never links to the terminology used in 4.5.1.5. For example, if there is no private-binding statement, it just says where the binding is accessible, but never says that the binding is public. I combined the material on this subject from both 4.5.1.5 and 4.5.1.6 and put it all in one place (4.5.1.6). Issue 41 There were 2 edits for [41:41-42], the differences being of substance, not just editorial. I guessed from context that the second was desired, but this was confusing. I also replaced the reference to abstract-interface-name at [47:26]. Issue 44 Reworded in conjuction with the combination of this material with that from issue 40. Also reworded the note a little. I was particular struck by the question of how one could identify whether a PRIVATE statement that was absent was a binding-private-stmt or not. One question remains. Issue 45 Some wording changes to simplify the sentence and eliminate the grammatically incorrect comma. Also changed the xref sections, which were misleading. (4.5.3.2 is specifically about overriding, not about declaring a proc-binding; for example, it doesn't have anything to do with declaring a binding that is not an override). Also fixed the implication that we "declare the dynamic type" of anything. It is actually the type definition that is of interest - not a type declaration. More like "the type definition corresponding to the dynamic type...". Also fixed the following sentence to use the phrase "the specified procedure binding". I couldn't figure out what the previous version actually said (though I know what it meant). Issue 47 "and" -> "for which" This is still quite a mouthfull, but I guess it will do. Issue 48 "not PRIVATE" -> "public" "PRIVATE" -> "private" "the" -"a" before the "PRIVATE" on [322:38] I don't see any referent for "the module". Added one. Issue 51 I italicized about 2/3 of the words to follow our glossary style. Paper 98-228r1, mixed public/private components, with changes It seems a bit redundant, every time we come to a place where there can be an access-spec or a PRIVATE statement, to repeat the constraint about this only being allowed in the specification part of a module. Plus we seem to have missed at least one place; it isn't mentioned for binding-attr. Rather than add it there, I've taken it out of all but one place - the first constraint in 4.5.1. That constraint already says "within the [type] definition" (I just added the "type" for improved clarity), and thus probably already could be interpreted to apply. I added a sentence to make this explicit by saying that this constraint applies to the other places in question. Then deleted the other specific cases of the constraint (the one that 98-228r1 proposed to add, the one added by 98-227, and the one that 98-227 missed...and I also missed when putting in 98-227). [48:1-5] In trying to decide whether the "a component" here should refer to "any" or "all", I decided that the difficulty was that it doesn't make much sense in the current context to refer to "the internal structure of the type" as an indivisible property, which is why I was having trouble. Some parts of the internal structure may be accessible, while other parts aren't. So mostly have this just refer to the accessibility of the individual component names. There are a few places where we require that all of the components be accessible. Currently, those places are few enough that it is as easy to mention them specifically (as we already do) instead of defining a general term. If we do decide to define something along this line, that would be the useful thing to define - the property of having no private parts. Perhaps we could call this the eunuch property. :-) But I don't think I need to define such a term at all right now, so I won't worry about its name. Also reworded the next sentence because it is no longer "simillar". Also inverted to say that private components are accessible only within the module instead of saying that they are inaccessible when access is via USE association (thus avoiding the issues of host association). The business about "only within the module" is the kind of phrasing used for other things also. Added a statement about component accessibility being the default if it isn't declared by an access spec for the component. Much like the existing statement for accessibility of the type. And changed "employed" to "used". Briefly debated whether "used" might be confused with USE association, but decided not, or anyway that I'd spent enough time on it. I'm a little leary of how "employed" might get translated - there are currently only 2 other uses of the term "employ" with that sense. Think I'll "downsize" them also. (In 15.9.21 and C.6.2). [48:28-32] Kept the order the same as the original, mostly because it was easier to type (and made me less likely to mess it up in the same kind of way as the R0 of 98-228). [49:7+] I rewrote the intro sentence of the note to say that it was an example instead of sounding like a requirement. And added a double colon in the declaration of M just because I think that better style. [49:7+] More importantly, I rewrote the last sentence of the note to agree with the normative text and other note. In particular, the component M%J is accessible anywhere that M is accessible; it does not depend on the accessibility of the type name MIXED. If we want this to be otherwise, we better say so in the normative text, and we better not make statements like that "the accessibility of a type name is independent of the accessibility of the components of the type." [54:26+] Added "of the type" for clarity. Also added "The type name". It is perhaps redundant, but no more so that the constraint on the components. [377:7+] Lower case "Types" and add a section ref like most of the other section headers in Annex C. I also have a feeling that a bit more on extensible types than this might be appropriate for Annex C, but I'll not do anything about it for now (or even make this a J3 note). The following are extra edits that 98-228r1 missed. (I grepped the standard for "public", "private", and "accessib" to find potential problem spots). [38:29] Add "some or all of" before "its components". While on the subject, moved this para at [38:25-29] to 4.5.1.6 (accessibility). It is certainly appropriate there, and I see no real reason why it has to also appear in 4.5.1.0. That move not really related to mixed pub/priv. Yes, I think I'm the one that subdivided 4.5.1 in the first place and presumably missed this obvious move then. [49:44] (in 4.5.2). Need to say that no components can be private. Also, type parameters don't have accessibility. Fixed. I think the last sentence of the 2nd para of 4.5.2 (determination of derived types) is redundant, but I didn't do anything about it. [82:44] (5.5). Add "any". [337:43] (15.1) Add "all". Paper 98-229r1, initial/final, with the following changes. The J3 note is numbered as unresolved issue 66. Paper 98-234r1, getenv, with the following changes. Add "character-valued" to the definition of environment variable in 13.11.4. From our perspective, this is part of the definition. Anyway, its all we deal with. (If some system provides other types of environment variables, they will have to either translate to a character form or say that those aren't environment variables as far as Fortran is concerned. In the later case, the system can either not support getting their values or provide extensions to do so. Followed the style of other entries in regards to bracket usage. Namely, use only one set of brackets around the entire set of optional arguments, rather than separate brackets around each one. (The brackets alone aren't sufficient to convey the full syntax of a call statement anyway, so we keep it simple). Corrected at least 2 different misspellings/typos of the word "environment", illustrating my concern that this name is going to be the source of a large number of user errors. Let me take this opportunity to plug for a spelling change in this intrinsic. Perhaps "get_system_variable". Nothing fundamentally wrong with the name as proposed except that it is easy to mistype/misspell. I didn't make a J3 note on this as I don't feel that strongly about it....but I'll stick this reminder here. "Get" -> "Gets" in the description to match style elsewhere. Upper case argument names; and no colons after them. Turned all quoted argument names into upper case, which seems to be the predominant style that I noticed elsewhere in c13. All the other argument descriptions in c13 seem to cram the whole description into one paragraph, so I did so here also. I'm not sure that is actually better, but the cases here read ok either way, so I'll go with consistency. For the INTENT(OUT) arguments. Don't say they have to be variables. The INTENT(OUT) says everything that we want to say in that regard (and we don't say variable in the other simillar places). "Blank padded" -> "padded with blanks" (partly because I had trouble deciding whether or not to hyphenate it. Looking for other cases to help me revealed that there weren't any). Will change all instances of future tense to present so that they had been consistent in tense. (Not like this para, for example). Either tense was plausible, but mixing them will not have been good. "the value" -> "it" in the sentence on blank-padding. Reorder the sentence on truncation to be parallel in construction to the sentence on blank-padding (this making it simpler as well). Copied some words from character assignment stuff (namely the words "truncated from the right"). I more than half think that we'd be better off referencing the intrinsic character assignment truncation and padding rules instead of essentially repeating them, but I didn't do anything about this (for now). Started email discussion about simillar issue for date_and_time; might end up with the same words in both (and other) places; might not. Reworded LENGTH so that the initial statement says that it returns a negative value as an error flag. Then list the specific negative values in a separate sentence. This avoids having the first sentence say what the allowed values are, and then having the second sentence say that, by the way, the first sentence wasn't really complete because other values are also allowed. Consistently talk about environment variables "existing" or not, instead of switching between that terminology and being "present" or not. "an environment variable name" -> "environment variable names" in the TRIM_LEN part. (I don't think we mean the concept of the processor supporting training blanks in some name but not others".) Made the "or" constructs in one sentence parallel. Paper 98-238r2, enums, with the following changes I flipped a virtual coin and added the new enum section after the new type alias section. (Both were added in the same place). Paper 98-240r1, C interop, with the following changes Added serial commas in several places. I won't bother to detail every one. The paper consistently used the opposite style from the one used in the standard. In new 4.6. Don't make a 4.6.1 subsection, since we have no 4.6.2. "Can" -> "may" in at least 2 places. Use restricted-type-spec instead of type-spec in bnf for type-alias. Change to integrate with explicitly typed allocs. I added a constraint that the type-spec not have any deferred or assumed type parameters. Perhaps this is or could be covered elsewhere, but we surely need it somewhere. Rather than saying that the declaration "is identical", say that it has the same effect. I might misinterpret the "is identical" bit to mean that it has the same syntax, which it doesn't. For example, if R is a type alias for REAL, the syntax for declaring a variable X is "TYPE(R) :: X", not just "R :: X", which is how I'd interpret saying that the syntax was identical. I assume we can let the syntax rules and examples show the syntax. The part that needs saying here is just what that syntax means. I omitted the proposed J3 note about typed allocations and array constructors because the edit at [59:26] adding type aliases into type-spec takes care of that. I presume this proposed note was written before the authors had a chance to study and consider the integration with the edits for typed allocations and array constructors (not surprising, since both edits were done at the same meeting). In this case, it looks like the integration "just works". Omitted the "For example" from the example. Deleted the "following" words to make the example code correctly fit in the grammar of the sentence in the example. I modified the example to include a type alias for a type alias. The syntax allows it, and I think it a natural question whether that is intended. The example would deflect such questions. Moved the sentence about derived type constructors up to the intro right after the other sentence about where typealias names may be used. Also reworded it because a derived type constructor doesn't have a name. In 2.1 I find myself a little mystified in trying to decipher the logic behind the ordering of the items in R207. (not that its a long enough list to matter a lot). If anyone figures it out, you might let me know. But I thought typealias fit better right after derived-type-def than after parameter-stmt. In the derived type edits 4.5 [38:33] I found the wording a bit roundabout. Too many "interoperate"s. It sounds redundant to talk about the requirements for interoperating with a struct that is interoperable. I see what you are getting at, but I found the wording confusing. I avoided this by talking about "the corresponding C struct as defined in 16.2.2. Also got rid of the "same as" bit to simplify things. [39:36+] In the second new constraint, singularized it. And changed to all present tense. Also changed the second "specified" to "defined". Otherwise it is open to confusion because the 2 cases of "specified" both apply to the same type name but are talking about completely different places. Merged the 3rd new constraint with the first one. [40:22+] Moved these constraints up after the [39:36+] ones. That's where the other comparable constraints are. Comparable in the sense that they are constraints on what can be in the derived type def depending on "global" attributes (like SEQUENCE, BIND(C)) of the def. And it makes precise wording a little simpler. In the proposed wording "*THE* derived-type-stmt" should more precisely be something about "the type being defined", which is the awkward phrase used on one other place. By moving the constraints, we don't have to use that kind of wording. In dummy data objects I didn't bold-face "VALUE attribute" because the sentence there isn't a definition (1.6.5 says when we use bold). This sentence is nothing but a restriction on what objects may have the attribute; it doesn't do anything to actually define the attribute. "Shall" -> "may". And reworded the sentence to simplify it quite a bit. We don't really need to talk about scoping units here. See how INTENT(IN) is specified in the constraints early in 5.1. I reworked the sentence about how it is allowed to explicitly specify the INTENT(IN), making it a clause of the sentence before (and eliminating the non-ISO usage of "can"). Added a "for" in the note. (Likely typo). Omitted the conditions about "for a procedure or subprogram that has the BIND(C) attribute" from the note because it is redundant. That's the only place where VALUE is allowed. If you want to restate that, ok, but we need to use slightly different wording. This wording implied that there might be other places where one could specify VALUE, but that this sentence applied only to these cases. "same...of" -> "same...as". Hyphenate pass-by-value twice. Added an xref to 16.2.4 in the note because otherwise it is not obvious where to find the normative that supports the statement in the note. [10:12+] This makes more sense to me at [10:46+] with the other attribute statements. I put it there. [60:46] "has" -> "have". [241:29] Just note that I long ago gave up on trying to understand all of these complicated conditions relating to the interactions of TARGET, POINTER, and other stuff for dummy args. So don't count on me to make sure the edits here make sense in this area. I just typed 'em in. In section 16 16.1 "A" -> "The" Kind values are not representation methods. They are just numbers. Along simillar lines, values don't have values; they may "equal" or "be" values, but they don't "have" values. Reworded accordingly. And used the same style for describing the integer, real, and character types, instead of having different wording for each group (for no obvious reason). "the values" -> "those" in the sentence about complex. Reworded the bit about C_NULLCHAR possibly being of default character kind in a way that is actually a little more complicated, but that I find easier to parse. 16.2 I pretty much rewrote the first para. I found it hard to read, without actually being precise. A derived type component is an entity, so it is confusing to say "a scalar entity or derived type component". There are no entities in the first column of the table, although there may be entities of the type specified in the first column. And I added words about the case where the parameter from ISO_C_TYPES is -1. And said something about the character length parameter (though probably not enough - see the J3 note). I let some of the fields in table 16.1 center vertically instead of top justify just because it was easier (that's the way the default template came up) and it didn't seem to matter. Simplified the table title. Changed the heading for the second column. Also slightly simplified the section 16.2 title. A slight wording simplification in the note after table 16.1 In the second note "access" -> "interoperate". Lets not mix these terminologies. "unsigned kinds" -> "unsigned types" when talking about C. 16.2.1. Again, a derived type component is an entity. I see this occurs several times more. I'm not gonna mention each one. "Fortran scalar entity" -> "scalar Fortran entity". Tried to make the wording in 16.2.1 a little more parallel to that in 16.2. In the note, "may" -> "might. (No permission is implied). SOme other rewording in the note. "Fortran 2000" -> "the Fortran standard." I don't think we want to bury something this version specific in such an obscure place. I don't much care whether we talk about interoperability of "entities" or "objects", but lets not randomly switch for no obvious reason. I stuck with entities (mostly because that's what the first cases used, so I made the later ones cobsistent). Xrefed 4.5.1 instead of 4.5 for BIND(C) in the derived type def. Why does it merit normative text to say that there is no Fortran entity that can interoperate with C bitfields and incomplete type stuff, but only an informative note for a comparable comment about C union types. I put the union stuff in the normative text along with the other stuff. Used our list syntax in 16.2.3. Rewrote the words in the example in 16.2.3 to tie the code to the sentence. You have to make some explicit tie in. You can't just make a statement and then present some code without somehow saying that the code has something to do with the statement. Used our list syntax in 16.2.4. Tried to put conditions in front of what they apply to instead of afterwards, also making the comma usage more sensible in the process. "subroutine or function" -> "procedure". I doubt that BIND(C) has asterisk dummy arguments. Presumably this is meant to apply to the procedure with the BIND(C) attribute. In the first note in 16.2.4. Hopefully this doesn't prohibit *ALL* dummyy arguments from being pointers, etc. I'd suspect that it only has much relevance to dummy arguments of procedures with the BIND(C) attribute. As in the previous code examples, made a sloppy attempt at connecting the words and the code. Changed a comma to a semicolon in the c func prototype. And removed the semicolon from the end (since we didn't have a semicolon on the end of any other C declaration samples). In 12.2. It looks funny to have 3 simillar phrases in a row, two of which say "whether or not", and one of which just says "whether". I flipped a coin and deleted the 2 "or not"s, partly because that was in the direction of simplicity (at no obvious cost in clarity), and partly because that's the way comparable stuff is a few paras later in 12.2.2.1. 5.1.2.4.4. Omitted a comma. 12.4.1.2. The edited sentence on the former page 242 was abysmal (the original, not just the edit). It has a confusing double negative (unless...not) and a structure messy enough that a grammatically incorrect comma was needed to make it readable. (You don't normally separate two "or" items with a comma). The edit provides an opportunity for slight improvement by swapping the 2 "or" items, since the second now no longer refers to the first (which meant it had to come second). Its still not great prose (I still don't like the double negative), but its a slight improvement. Paper 98-241r1, renaming operators, with the following changes. The terms defined-binary-op and defined unary-op already include the constraints about not being the same as intrinsic operators or logical literal constants, so deleted the repetition of that constraint for local-defined-operator (as it already is constrained to be one of the 2 things that already have that constraint). Added "Each" to the local-defined-operator constraint. Put the xrefs of R703 and R723 after the first use of each term instead of after the second. [225:11] Made the defined op 3rd item in list instead of 2nd. [225:21] Put the defined operator after name instead of before it. (Because the name case is the main one). Added "and defined operators" after "Generic interfaces" on [225:24]. I assume this is wanted. It really stood out to say at [225:23] that generic interfaces and defined operators were the 2 exceptions, and then to say in the next sentence how only one of those exceptions was handled. It sure left me wondering about the other one. I could not follow the intended edit for [225:18]. I assume the trailing comma was supposed to be the missing close quote, but I couldn't make any sense at all out of the resulting sentence. Maybe that comma wasn't really the end and it was missing part of the edit. I think I know what case needs to be covered for that item, so I just rewrote [225:17-18] to do so instead of adding an unresolved issue. Let me know if I screwed it up too badly. Paper 98-242r1, misc edits, with the following changes. Item 1 said to find and simillarly change all other references to the IEEE standard. I grepped for 754 and 559 to find these. In addition to the ones mentioned in items 1 and 3, I do did in note 4.9, two cases in 15.3, one in 15.6, and one in 15.7. Item 2 - superceded by subsequent email from Miles. Item 9,23 - put the "any number of" before "blanks" so it applies to both blanks and ends of records. Seems odd to say it explicitly for one and not the other. Item 13 - the J3 note is numbered as unresolved issue 63. Item 17 - used "with the value YES" instead of "with a value of YES". (Otherwise it almost sounds like we are suggesting it might be one of the values that YES might have). Item 18 - slightly reworded the sentence to clarify referents so that we don't have "components that is not processed..." (the "that is not processed" was supposed to refer back to "object", but it sure was easy to read this strangely. Item 19 - the J3 note is numbered as unresolved issue 64. Added a sentence suggesting that the answer might be influenced by the resolution of unresolved issue 63. Item 22 - the J3 note is numbered as unresolved issue 65. Paper 98-243r1, explicitly typed array constructors, with changes [56:25] Delete "the" (mostly for consistency; is ok either way). [56:25+] Delete 2 "then"s (also for consistency) The J3 note is numbered as unresolved issue 82.