J3/98-204 Date: 2 Oct 1998 To: J3 From: Richard Maine Subject: Edits incorporated in 98-007R3 This paper describes the changes in J3/98-007R3 relative to the previous f2k draft, J3/98-007R2. All page/line references are to J3/98-007R2 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 98-007r3 are relative to 98-007r2 Paper 98-184r2, select type, with the following changes Since it seems like a lot of pointess work to define statements and then not allow them to actually appear in any context in Fortran code, I added select-type-construct to R215. :-) [47:36+] This paragraph defines the terms "ancestor" and "nearest ancestor." Other than in this paragraph, the word "ancestor" appears only one time in the edits of this paper (and nowhere in the standard previously). That one time uses it in the context of "nearer ancestor". It seems silly to go to all the trouble to define "nearest ancestor" when we never use the term in quite that way. I'll see if I can just reword the one use in terms of existing terms instead of introducing 2 new ones. See also unresolved issue 53 for a related question about terminology (one that was at issue even before this paper). The introductory sentences of the SELECT CASE and SELECT TYPE construct sections sound identical. I added an extra introductory sentence to each to explain the general nature of the distinction. "The selection is based on the (value/dynamic type) of an expression." While on the subject, added two simillar sentences to the introduction of the IF construct and statement, and changed "no more than one" to "at most one" so that we boringly use the exact same phrase for the exact same concept. 8.1.4.1 Use bnf terms in constraints where applicable. And in particular, use type-guard-stmt instead of just "guard statement", the latter term never having been defined. If we did use a non-bnf term for it, it would have to be "type guard statement", which is implied by the bnf term. Constrain against things happening more than once, not against there being two of them (lest someone claim that its ok if there are three). I rewrote the last constraint in 8.1.4.2 to conform to the specifications. As written in the edits, it didn't say that there could be only one type-guard-stmt. It said there had to be either a matching TYPE IN or a default, but there was no constraint against having both or against having additional non-matching type guards. (The English term "or" is not an exclusive "or", and a constraint that there be "one" statement is not the same as a constraint that there be "only one"). This raises another question in unresolved issue 57. Last sentence in 8.1.4.1. "assume" is used inappropriately here. Assuming something to be true is not the same thing as specifying how things will work. The usage is at best vague, and possibly contradictory (if interpreted as assuming something to be true when it isn't). I reworded. Association is "with" not "to". I have no idea why you would want to restrict SELECT TYPE statements against being branch targets. I assume this meant to apply to type guard statements, which would make sense and be parallel with the CASE construct. Fixed. Changed "assumed" to "implied" a few times in comments in examples. Simillar issue to above. In addition to the "assumed" problem, the grammar of the intro sentence to the second example didn't work, so I simplified it. Added an xref to say that the secoind example uses the declarations from the first. [303:34] The edit at [309:40+] includes associate names under the heading of "statement and construct entities" (as I agree is appropriate). Therefore the edit to [303:34] is unnecessary and confusing.....in fact, now that I look at it more carefully, it would also be wrong. The "not" on [303:34] applies only to the "statement and construct edtities". The proposed edit would have put "associate names" in as part of the list that the "not" does not apply to, thus saying the opposite of what it intended....unless I'm really confused and you do want these to be local entities of the scoping unit, which I seriously doubt. I omitted this edit. All seems correct without it. [309:40+] "The" -> "A". Used bnf for associate-name. Paper 98-186r1, partial type bound proc edits, with the following changes [39:29+] It seemed inconsistent to have component-def-stmt broken down as either inline syntax for data components or a separate bnf term for proc components. They should be more parallel. After experimenting the other way (both in-line), I decided to make them both separate bnf terms. Did this by adding the bnf term data-component-def-stmt. [40:22] The constraint on pointer being specified is wrong. This shouldn't be a constraint on R432b (proc-component-attr-spec). This is a constraint on the proc-component-attr-spec-list that appears in R428. As phrased, it applied to every individual proc-component-attr-spec, thus meaning that you could never actually specify PASS_OBJ. I fixed this. I added a note referencing 5.2 for the definitions of the bnf terms proc-interface and proc-decl. If I'm the only one that had trouble following the forward reference without this, we can take it out. Fixed a typo "tha"->"the" while in the area. Nothing really to do with this paper. The PASS_OBJ paragraphs had several problems, one of which I fixed. It makes no sense to say that something has "the same type as type-name". Type-name doesn't *HAVE* a type, it is the name of a type. I fixed this one. For the others, see the J3 note. I couldn't determine the reason for introducing the binding-by-name bnf term. It looks like just an extra level of bnf that doesn't add anything and is not referenced. I collapsed it out of the bnf. Trivial enough to add back in if there was some inner reason that I missed (which is certainly possible). If we do put it back in, then it will have to have a different name because it doesn't conform to 1.6.3, which would imply that it should syntactically be a name for a "binding-by", whatever that would be. The statement "If => binding is absent it is assumed to have been present.." is self-contradicting. Instead of "assumed to have been" you mean something like "as though it were". Also, avoid using the "absent" and "present" terminology, which we mostly reserve for optional arguments. Instead, talk about it being specified. And don't say "the same name as binding-name". By construction, binding-name *IS* a name, it doesn't *HAVE* a name. It is the binding that *HAS* a name. I moved the syntax rule (and its constraints) for deferred-binding from 4.5.1.5.1 up into 4.5.1.0 for consistency. All the other syntax rules for that section are together in 4.5.1.0 instead of in the subsections. While on the subject, I couldn't see any reason why deferred-binding needed to be a separate rule anyway; merged it into the syntax rule for binding, makeing one less level of complexity. Added "accessible" to the abstract interface constraint. If we need to say it for the procedure name (which we probably do), then it should be equally necessary for the abstract interface. "present" -> "specified". "4.5.1.3" -> "4.5.3.1" as an xref for inherited multiple times. Several mods in the bnf for select-kind construct. As in the paper, the use of the ellipsis didn't conform to 1.6.2, which shows it only after optional items. But then I think we did want proc-binding construct to be optional. Am I correct in thinking that 0 or more proc-binding-constructs per case are allowed? And I assume that multiple cases are also allowed, so I added a second ellipsis after the case "block". [44:22+] Added "in a proc-binding construct" just to provide more context, since this is several pages afterwards. Eliminated the 4.5.1.5.1 section heading. I prefer to avoid subsectioning where there is only one heading at a level (there is no 4.5.1.5.2). Plus, this is short enough not to really need a separate level. There is only 1 short paragraph plus a note in 4.5.1.5, and then three more short paragraphs in the proposed 4.5.1.5.1 (at least after I moved the bnf stuff out). Besides which, I prefer to keep down to 4 heading levels where reasonable to do so. I don't like saying that a binding that specifies NULL creates a procedure. First, I don't like the word "creates". That implies run-time action. Second, I don't like calling this "thing", whatever it is, a procedure. We have a definition of a procedure and this doesn't fit it that I can see. Indeed, I don't see any "thing" to call a procedure here at all, unless you are saying that the NULL intrinsic is the procedure, which doesn't sound right. The processor might implement deferral by in essence binding to some error procedure, but that's an implementation strategy. I think a better phrasing is to say that the binding is deferred instead of to say that it is a binding to some non-existant "deferred procedure." Doesn't really change very many words. Indeed, I see that some of the words elsewhere in the paper refer to it this way anyway; for example, 4.5.3.3 says "binding...shall not be deferred" instead of saying something like "binding ... shall not be to a deferred procedure." Reworded along these lines. Reorder sentence about extensions to avoid parsing ambiguities. "contain" -> "specify" I don't think it is really necessary to xref the term inherited 3 times in the space of 3 short paragraphs; the first of the 3 seems sufficient. "possible" -> "permissible". They are different. We mean permissible. "null binding" -> "deferred binding". Lets always use the same term. [47:39-44] "Inherited" is already in the index pointing here. Do you really want both forms? Seems pointless (particularly since we don't actually use the form "inherit" here). I didn't. I had trouble reading the proposed 3rd sentence of the inheritance section (explaining that inherited entities can be further inherited) unless I already knew what it was trying to say (which I did). But I think the sentence is superfluous anyway, since the first sentence says that *all* of components etc are inherited. 'Tis true that elaboration wouldn't hurt, but rather than spend time trying to improve the words to make them clarify instead of possibly confuse, I just left 'em out. Components, type parameters, and bindings are not "entities" as currently defined in the glossary. I suppose we could fix that, but I found it easier to just avoid using the word here. (The one use left converted easily to a "they"). Add a "the". Add "derived type definition of the". Parameters are declared in a derived type definition, not in a type. [48:28+] Bindings don't have several of the propertied mentioned in the proposed restrictions in 4.5.3.2. These are properties of the a procedure, not of a binding. For example, a binding is not a subroutine. Reworded and reorganized all of these quite a bit to fix this. While on the subject, pulled the last item out of the list because it isn't paralell to the others. The other items are all restrictions on how things must be consistent. The last item is a definition of overriding. I moved the definition to before the list. I don't know what it means for something to be accessible "in an object". I don't think what you are trying to say has anything to do with acessibility. I floundered around trying to come up with better words, but decided that the preceding sentence about overriding already said it about as well as anything I was coming up with. So I just deleted the sentence about accessibility. Feel free to try to add something to elaborate better, but I don't think that dragging accessibility into the picture is likely to make things clearer. "one" -> "a binding". Otherwise the antecedant of "one" is unclear. (It could be "binding" or "binding name"). Also add "declared in a type". I couldn't find anything that said what happens when you leave the abstract interface off of a deferred binding. So I added something. (The interface is the same as that of the inherited binding). The proposed 1 paragraph section 4.5.3.3 on procedure binding accessibility seems out of place as a subsection of extensible types. I don't see that this says anything specific to extensible types at all. I don't see anything that restricts type-bound procedures to extensible types, and I think I recall this being intentional. I put this as a paragraph in the section on accessibility. The section on type-bound procedures would be the other possibility, but I thought this one slightly better. [224:8+] I didn't see any benefit in introducing the extra level of syntax for type-bound-proc-name, so I collapsed that level. About the only thing it had seemed to save was to do the constraint once instead of twice, but the constraint needs to be different for the 2 cases anyway because the original neglects to constraint function references to refer only to functions and subroutine calls to refer only to subroutines. In the constraint, we don't have a procedure binding "to" a declared type. Follow the wording style of simillar constraint after R613 and say that it is "the name of a binding of the derived type definition of the declared type". Moved the 2 sentences down to where they apply to both functions and subroutines. [225:11] The proposed edit was ambiguous as to whether it applied to just functions or to both subroutines and functions. It also failed to consider the use of PASS_OBJ with procedures that are not type bound. Rather than add further complication to this sentence, I left it untouched. Tried to integrate the PASS_OBJ stuff a little better instead of just describing how argument association works without PASS_OBJ, and then separately stating how it works with PASS_OBJ. Did a bit of rewording and re-odering in 12.4.1.1 to achieve this. [225:36+] Several of hese words were integrated into the preceding paragraph, so we no longer need to repeat all the business about keyword vs positional. We just need to point out what happens to the PASS_OBJ argument. Some questions left to an unresolved J3 note, A few other fixups already done. Lets not introduce "annotation" as a new term for attribute. We have enough confusion already between attributes, charactersitics, properties, plus terms like specification. I don't think we need a new one. (Yes, using the same terms all the time does make for boring reading - standards tend to be that way). Added "of the or " after "the "with". Suggested wording just complicates the sentence without really adding anything. If you are refereing the procedure other than through the binding, then it isn't being referenced as a type-bound procedure. Actually this suggests to me that the term "type-bound procedure" is not the best form. There is nothing about the procedure itself that makes it type bound. The type-bounding has to do with how the procedure is referenced rather than with the procedure itself. Association is "with" not "to". We don't need to repeat the same xref for the same term in 2 consecutive sentences; the first one will do. [307:4,9] I don't understand the proposed xref to 12.4.1 here, so I omitted it. It is either misplaced or too subtle for me to understand. This is in the middle of a section talking about procedure references. If we needed an xref for the term "procedure reference", it would make more sense to put that xref near the beginning of the section (14.1.2.4) rather than at 2 places in the middle of the section. I don't see what distinguishes these two places. And the "obvious" xref for the term "procedure reference" is 12.4 instead of 12.4.1. Perhaps this was supposed to clue the reader into something subtle. If so, I'm afraid it went right over my head, and I doubt I'd be alone. Of course, I'll admit that most of 14.1.2.4 is [308:33] Since the term "subobject" doesn't appear in this section, it doesn't seem appropriate to put it in the section title. If the contents change later, then the title could also change then. [346:37+] I couldn't find where this was supposed to go. The cited page/line would be at the end of the definition of "nonexecutable statement", which doesn't make much sense. So I omitted it. [349:26+] I took the last sentence of the definition. It has worse problems than I feel up to fixing right now. And since it isn't really necessary to the glossary entry, it seemed easier to eliminate it than to fix it. See unresolved issue 40 for some simillar questions on the normative text where I couldn't get by with just deleting it. [312:41+] I think we want to say that it is execution of the SELECT TYPE statement (as opposed to construct) that establishes the association. And then change "in the select type statement" to "in the statement". In either case, capitalize SELECT TYPE. Also use bnf for expr and asssociate-name (particularly the latter, as it helps keep one from trying to interpret the associate in "associate name" as a verb). Changed the second "Thoughout execution of the select type construct" to "Within the SELECT TYPE construct" (unless we are suggesting that the associate-name is also automatically accessible in any subroutines that might be called during execution of the construct). The phrase "termination of execution of" is ok, but I think it reads a little more easily as just "termination of". We do elsewhere talk about termination of a DO loop without the extra "execution of". Paper 98-187, i/o fixes, with the following changes Slight rewording of the second edit to avoid possible confusion about the antecedent of the "it". Paper 98-189r2, derived type i/o enhancements, with the following changes Added unresolved issue 23 and J3 note. [170:19-21] Put the "of the edit descriptor" phrase after the "if any" instead of before it. Otherwise it sounds like the "if any" is saying that there might not be an edit descriptor instead of that the edit descriptor might not have a char-literal-constant. "v_list" -> "The v_list argument" twice to avoid starting a sentence with "v_list". [170:27-19] "specified" -> "specifies" to avoid switching tenses. Other simillar references in the para all use present tense. [193:37-41] "contain" -> "include" [193:37-41] Added "of the edit descriptor" after "the v values". Otherwise it sounds like the v values are part of the char-literal-constant that was being discussed in the preceding 2 sentences. Paper 98-190r2, i/o rounding, with the following changes 155:4+ "This" -> "It" "specifiers correspond" -> "specifier values correspond". (There is only one specifier; it has a list of possible values). Made the 2 sentences in the 2nd para be 2 clauses of one sentence. These clauses need to be closely linked because the condition mentioned in the first ("If this specifier is omitted") also applies to the second. "shall mean" -> "means". This isn't a requirement; it is a definition. We reserve shall for requirements. Besides, "means" was used in the same way in the first part of the same sentence. The form (0.110)_2 neither corresponds to Fortran syntax, nor a widely accepted mathematical form. It sort of looks like the 2 is a kind number, but isn't quite the right syntax for that (and that's not what is meant anyway). What is meant is obviously "base 2". I don't see an easy way to write that in Fortran. (Boz integers can only be used in a DATA statement, so they don't help). I wimped out and changed the "(0.110)_2*2**(-3)=3/32" to just "3/32", which I think is probably just as clear anyway. And deleted the "with 3 binary digits", which doesn't look like it adds anything. If we really want to spell out the bits, we might need to be a bit more verbose - possibly referring to the model for real data in 13.7.1. "with" -> "by" ("by" goes with "represents"). Cut the size of the big para in half by using one general sentence that applies for either direction of conversion instead of 2 almost identical sentences, one for each direction. I found it difficult to read the original version because there were so many almost identical words that I kept losing my place. I notice that the last case (nearest) was already done somewhat like this. In support of this, added the following introductory explanation to the preceding para: "Formatted output of real data involves conversion from an internal value to a decimal value; formatted input involves conversion from a decimal value to an internal value." Oh. While redoing that para, I noticed another problem. There is no such thing as an UP specifier. There is a ROUND= specifier, which might have the value "UP". I changed all things that said stuff like "when the UP specifier is in effect" to "when the rounding mode is UP". And moved that phrase consistently to the from of each sentence, which I think makes them a little easier to read. Since section 1.9 lists ISO/IEC 1559:1989 as the normative reference, we should use that one instead of the IEEE number when we specifically cite a standard number. So I did. I presume that the section reference to 5.6 in that standard is still correct. Same change in section 15. [187:3] reordered the list. Also "descriptor" -> "descriptors". [196:25+] Change this to a numbered list (because I have a format for that). Delete "it is as if:". I don't know what that means. If (as is my main suspicion) this phrase is intended to mean that the processor doesn't actually have to do it that way, but just has to make sure that it gets the same result, then we already have words to cover that in much more generality. Instead of using the term "external representation" when talking about input, and then "converted character string" when talking about output, use "external decimal value" and "converted decimal value" to better match the terminology used in 9.3.4.x. Likewise, use "internal value" instead of "internal representation". [196:40+] "specifiers" -> "specifier values". UP, DOWN, ZERO, NEAREST, and PROCESSOR_DEFINED are not specifiers. And while on the subject, I made the RU, RD, RZ, RN, and RP descriptors actually do something instead of just sitting there and corresponding. The original edits didn't ever say that these descritors set the rounding mode. We said that they can be used to control it in some unspecified fashion. And we went to a fair amount of trouble to say what the initial rounding mode was. But then we never said that these descriptors set it. I also added words to say that the rounding mode remains in effect until the end of the statement or until changed by a subsequent round edit descriptor. This wasn't explicitly said elsewhere. [335:38+] I made the result of IEEE_SUPPORT_IO be a function of its argument. (The description of result value had failed to do this, although the example implied it). Also changed the IEEE citation to the ISO one as mentioned above. Paper 98-191r1, volatile, with the following changes Several punctuation changes not detailed here. One "which" -> "that". I deleted all the "attempt to" phrases. I don't think it makes sense to require a processor to attempt to do something. Looks like all of the uses were in the context of "should attempt to" and were in notes. The "should" is sufficient alone for this purpose and is the ISO-preferred form for such things. Table E.2 of ISO directives 3 says to use this form "...to indicate that...a certain course of action is preferred but not necessarily required...". This fits fine. The processor "should" use the most recent definition, etc. We don't need to say that it "should attempt to" do so. Deleted the constraint in the new 5.3.x. As mentioned on the floor, (with no objection expressed) this constraint is redundant with the one after R506. Other simillar cases are inconsistent as to whether they have such a redundant constraint or not. The editor thinks it is better without this particular redundancy. [211:33-36] I can't see any change here except for the addition of "or VOLATILE". That's all I did. If there is something I missed, please let me know (and please note that it would be a lot easier on me if the change had been expressed like that)." [18:35] I had a couple of trivial changes to this sentence. And I also initially added a J3 note saying that the proper way to deal with this was to add an item in 14.7.5, in which case we wouldn't need to say in 2.5.4 that there is a case not covered by section 14. But I later see that the paper did, in fact, add an appropriate item in 14.7.5, so I don't need my J3 note. But we also don't need this sentence in 2.5.4 at all; the section 14 reference covers it. Unless we are going to also call out each the other 22 items from 14.7.5 into 2.5.4, I suggest that we not call out this one either. The proposed wording implied that this was a case not covered in section 14. I deleted it (along with my J3 note). [54:43+] Turned the clauses around so that the single attribute appears in the if clause. Seemed to work a little better that way. [66:10+] "2.3" -> "2.3.4". The rest of 2.3 didn't look relevant. "but need not have it" -> "without necessarily having it" I'm going to ignore the fine point that we don't normally consider an object to be in more than one scoping unit. Instead, we usually talk about them as being technically distinct objects that are associated. If someone else wants to fix the wording here to be consistent with that, feel free. Added "of a volatile object" after "definition" in the note. [71:4+] "declares" -> "specifies" [318:37+] "a" -> "the" (there is only one volatile attribute). Delete "as". [361:5+] Added a section ref to the title, like other simillar cases. Added a comment about needing a formal reference to the J3 note. The "text" file was full of tabs, which all detabbed incorrectly in the editor I was using. Please do not use tabs in text that I'm likely to be inserting. I had to manually fix all of these. Paper 98-192r1, misc editorial changes. Paper 98-199r1, i18n, with the following changes [155:4+], [161:7+] "This" -> "It" (twice). [161:7+] "in" -> "for" Deleted "at the beginning of execution of each formatted input/output statement for a file connected by an OPEN statement". It made the sentence hard to parse, and didn't appear to say anything not said by the rest of the sentence. [180:25+] "one of the values" -> "the value" The original wording copuld be interpreted as saying that both values COMMA and POINT might correspond to the mode in effect and that the compiler could pick either one. "the file" -> "a file" [187:3] "descriptor" -> "descriptors" (there are 2 of them). [196:40+] "that" -> "which,". (We have a lot of cases where people write "which" when they mean "that". This one, however, does need to be "which", unless we are implying that there are multiple decimal edit modes, and that we are only talking here about the one *that* controls the appearance of the decimal point...) I omitted the xref to 9.3.4.x. It seemed misleading in context. Looked like it was implying that you'd look in 9.3.4.x to find details about the fomatting controlled by the decimal edit mode. Instead, all that is in 9.3.4.x is how to set the default value in the OPEN statement - nothing at all about what it does. The (brief) words about what it does are right here in 10.6.x. "initial edit mode" -> "initial edit mode for that statement" to be more specific (and hopefully more clear). I found the senetence beginning with "If no DECIMAL=.." both hard to parse, yet also incomplete. PRINT and one form of READ don't have an io-control-spec-list, so its not really adequate to just talk about a DECIMAL= specifier not being in the list. Also, this section neither mentions the cases of internal or preconnected files, nor does it xref anywhere that does. I did some rewording. But I didn't fix unresolved issue 30. I'll let someone else track down all the cases of it and handle them all consistently. "DC sets" -> "The DC edit descriptor sets" mostly to avoid starting a sentence with "DC". And combined the DC and DP sentences into one. And, as with the round specifiers, I added words about the decimal ones remaining in effect until.... I changed "in this standard" to "elsewhere in this standard". Unless the paragraph is not actually intended to become a part of the standard, I think the original version was self-referential and contradictory. This is, however, a "quick fix". I'm going to add an unresolved issue for doing it right. And I changed the wording to say things more like "a comma shall be used instead of a period to represent the decimal point in a number". This may not be the best wording, but at least it makes sense. I'm sorry, but a comma is not a semicolon, no matter how many "shalls" we put in front of a claim that it is. (I suppose a comma might be a decimal point - I'm less sure about that one). What we mean is not that a comma is a semicolon, but that a comma should be used instead of a semicolon. Again, this is a "quick fix". I'm dubious that its acceptable for the final document. [197:23] Omitted "as a value separator" since this is already in a sentence that begins "A value separator is". And added a comma. [198:10] "semicolon" -> "comma". Presumably a typo. [198:12], [198:15-16] The proposed last sentence is just too clumsy with the phrase "or a semicolon if the decimal edit mode is COMMA" twice in the same sentence. Redid this para to just refer to a separator and then say that the separator is a comma or a semicolon. [200:12], [200:14-15] Define the separator, much like [198-12-16]. [205:3], [205:5-6] Same. [202:6] "controlled by" -> "dependent on". "Controlled by" is too strong here. And I changed the form to singular. Then changed "the" to "an" in the next sentence to avoid possibly being misinterpreted as referring only to a real of complex one. [204:31] I disagree with the statement that just because [204:28] says that namelist output is the same as input, this allows us to ignore the fact that line 31 contradicts it. I added the same "or a semicolon.." bit as added elsewhere. [250:37+], [293:14+] I made the argument name NAME instead of R. The R name in selected_int/real_kind stands for range, which doesn't seem very applicable here. Yes, this is a technical change. Will undo if folk are unhappy. [293:14+] "its argument" -> "the argument". Or it sounds like an argument of the character set. "Result" heading "Result value" as we have a separate heading for the result characteristics, so this subsection isn't everything about the result. I rewrote the ISO10646 sentence because the way it was originally, it said that the result was -1 if the name was anything other than ISO10646. (You only want the "otherwise" to apply to the "if the processor supports" part, not to both the "if the NAME is ISO10646 and the processor supports" conditions.) To make the wording style consistent after this change, I also reordered the clauses in some of the other cases. We never actually say what happens if the NAME is the name of a processor supported character set other than DEFAULT, ASCII, or ISO10646. I added such a statement. Consistently talk about a character type instead of a character set. (There might, for example, be 2 different types that had the same character set, possibly with a different collating order). I added a sentence in 4.4.4 refering to selected_char_kind. Sections 4.4.x have simillar sentences about the other selected_*_kind intrinsics. Paper 98-200, more misc editorial changes. Paper 98-201, polymorphic pointer changes, with the following changes Also deleted the 2nd half of the first J3 note in 7.5.2 (part of unresolved issue 20). The edit to 123:16-17 answers the request for some kind of compile-time constraint.