J3/02-209 Date: 31 May 2002 To: J3 From: Richard Maine Subject: Edits incorporated in 02-007R2 This paper describes the changes in J3/02-007R2 relative to the previous f2k draft, J3/02-007R1. All page/line references are to J3/02-007R1 unless otherwise noted. Because we are nearing CD, I generally did a lot less editing of passed papers than I have been doing in the past. The CD needs to reflect J3's votes rather than my personal fixes. There are quite a few things (mentioned below) that I think should be fixed. Note that this will apply even more for the actual CD, which presumably will be the next revision. Whatever J3 passes will be pretty much what goes into the CD. I'll still correct typos and spelling errors, but if you pass something that is written in such a convoluted manner that nobody who wasn't involved in writing it can read it, then that's what you'll get in the CD. If you don't want it in the CD, then don't pass it. Also, because the CD will have no unresolved issues, I was a bit more reluctant to add unresolved issues this time through. I started out intending to add no unresolved issues, but then made exceptions for a few things. I'm sure that I ended up inconsistent about what issues ended up as unresolved issues and what ones are just noted below. You will find several comments below that I previously would have made into unresolved issues. Some of these are significant in my opinion, so I'd advise actually reading this paper. This includes edits from papers (all 02-): 166r2, 167r1, 169r1, 170r2, 171r1, 173, 174r2, 175, 177r1, 178r2, 179, 180, 181r4, 184r1, 185r2, 186r1, 187r2, 188r2, 189r2, 190, 191r3, 192, 193r1, 194, 195, 196, 197, 198r1, 199, 202r1, 203r2, 204r1, 205r2 Editorial/typo fixes not in papers [490] Fixed index entry for "NAME= specifier". Fixed LaTeXisms in the section title for 13.8.3. Their most visible effect was extra space at the beginning of the title, most apparent in the table of contents. paper 02-166r2 with the following changes There are no bnf terms for several of the "-name" things so marked in the LaTeX source (doesn't affect the appearance here, but does cause LaTeX to gripe and it affects the index). There is no such thing as a "proc-declaration-stmt". I fixed these. [xiii] That list uses periods, not commas. [80:23] Two out of two for trivial list inconsistencies in the first two edits. All the other items in this list use articles. After not too much thought, I factored the articles out of all the items in the list instead of adding one to this item. Hmm. Unrelated to this paper, I see that the first sentence of 5.1.2.6 confuses the name and the entity named. In that it is contradicted by words later in the subclause. I'll not try to fix this (and I'm afraid that although some places show evidence of trying to avoid it, the error slips through in many others). [80:23-26] I don't understand the deeper reasoning behind having xrefs for every item in this list except for interface body, which had one before the edit. Perhaps the deletion of the 12.3.2.1 xref was accidental, but I couldn't tell for sure, so I entered it as specified (well, almost - I didn't double the period). [80:36-38] I started to rewrite this to eliminate its confusions. However, insomuch as Van clearly finds different things confusing than I do (see 02-190), it is inappropriate for me to just rewrite what J3 passed. If we weren't coming up on a CD, I'd do an unresolved issue on it. But since we are, then J3 is going to just get what it passed. If you want it right, you'll have to pass something that is right. In the second and third sentences of this edit, the "it" clearly (to me) refers to a name that has the external and pointer attributes, which certainly isn't intended (and makes the 3rd sentence self-contradictory). In the 3rd sentence, you probably mean to refer to the name being used in these contexts rather than actually being these things. We don't say, for example, that a name *IS* an actual argument - that is not a property that a name can have. We say instead that a name is used as an actual argument. See examples multiple places, I'm sure, starting with the imediately preceding para. In the 4th sentence of the edit, the referent to "the name" is pretty unclear, but I'm sure that neither of the two grammatical possibilities are what you meant. It could be referring to the closest preceding possibility, which would be "the name of an external procedure". Or it might possibly be referring back to the beginning of the preceding para for "a name that has the EXTERNAL attribute and the POINTER attribute". I can find *NO* justification for interpreting it as what you presumably intend. In the 5th and last sentence of the edit, it is manifestly unclear what the "above" referred to in the last sentence of this edit means. I think that perhaps it is supposed to mean everything above it in the edit. That might read fine when the edit it out of context. But when put in context, I have no idea how the reader is supposed to conclude that "above" means the preceding two paragraphs, but not any more. Two is a really hard number to justify in such context. I see no special demarcation to give a hint. If the reader includes the third para in "above", then the meaning becomes entirely different. Is the 5th sentence intentionally going out of its way to avoid saying what it means, or is it's meaning more subtle than I understand? This sentence never says what the name would then represent - just that whatever it represents is a local entity. Am I correct in guessing that this is trying to say that the name is the name of an abstract interface? I just can't tell. It seems to be implying that procedure pointers and dummy arguments are not local entities, which contradicts the definition of "local entity" (See the glossary, 16.0, and 16.2). I can't even attempt to rewrite this without first figuring out what it is trying to say, which confuses me more the longer I look. [254:13-14] I agree that the binding label seems inappropriate as a procedure characteristic. But if you delete this, you might also want to detete the sentence at [392:21-22] about binding labels of dummy procedures. I bet (but cannot verify) that the only reason for that sentence was as a hack so that we could still claim that actual and dummy procedure characteristics agreed, even when binding label was called a characteristic. I sure can't see why else that very strange definition was adopted. I just entered the edit as is, but J3 might want to consider more. [255:5+] Did you intentionally exclude the characteristics of the dummy arguments? I see that you deleted them from the definition of procedure interface, but failed to add them in here. I don't know whether this is supposed to be some subtle change or whether it is an error. I suspect the later - it seems pretty seriously wrong to me. [257:20-24] We use \mindex instead of \index. Also, did not double the period. Perhaps I'm just missing it, but it seems to me that you deleted something of major importance here without providing it's substitute. Where is it that we now say that if the interface has the same name as a dummy or external procedure, accessible in the scope, that the dummy or external procedure has that interface? Hmm. Perhaps the last sentence of the edit is supposed to make that point. If so, it is certainly obscure (and I think wrong also). Are we getting names and entities confused again? There are branches of philosophy where an entity and its name are the same thing, but I don't think Fortran is among them. Is it a name or an entity that has an interface? Looks like 02-177r0 was closer to the mark here. [262:23] the snref for R1215 is still abstract-interface-name. It was right one place and wrong the other. (problem in the LaTeX, not in what printed). [277:12] As currently written, I'm not quite sure how one defines that an interface body is "for" a dummy procedure. Yes, I know how to tell in practice - what I can't do is find it in the draft standard. Related to comments on 257:20-24. [396:12] Ok here, but I thought that we had concluded in an earlier life that we needed a similar exception in the next para (so that an interface name can be the same as the name of a local dummy argument or procedure pointer). [419:6] If we still want to elaborate everything that might be called an entity (which I never have thought appropriate), we may need to add "interface body" here, though I'm not sure. paper 02-167r1 with the following changes As with 02-166r2, There are no bnf terms for some of the "-name" things so marked in the LaTeX source. C453 2/3: "" -> "" [47:6,9] This (former C456) appears to distinguish between explicit and implicit specification of PASS - that is specifying PASS does *NOT* just confirm the default. Is this intentional? If not, this needs to be fixed. If so, it seems that several cases are omitted. For example, can you implicitly specify PASS (by specifying nothing) for some bindings, and specify NOPASS in others of the same generic (hopefully not)? Perhaps this would be better done as in the [58:6] edit. [47:18-20] Also deleted the "If" and the period. [58:9+] Shall correspond to what? And by what definition? By name, position, either, both? [266:12] Deleted this xref instead. Having the same xref for the same term twice in a single sentence seems unnecessary. (The previous edit inserts the same xref earlier in this sentence). [266:16] Also changed the keyword index entry here from PASS_OBJ to PASS. (There are several reasonable possibilities, but leaving it as PASS_OBJ clearly wasn't one of them). [266:17,20] Similarly, did a little bit of xref control here. In this case, we have 3 xrefs for the same thing in two sentences. We don't actually have to tack on an xref every time a word appears - in fact it gets pretty distracting. I eliminated all but the first. (The 4.5.1 xref on 266:19 is the second - that one should have gotten moved to xref 4.5.1.6, just like the 266:12 edit, but even better, I deleted it). paper 02-169r1 with the following comments If I could figure out what the para added by this paper was saying, then I'd be making big bucks as a mind reader instead of writing standards. I thought at first some lines must have been dropped from the middle of it. Fixing the grammatical problems might help a little (is there perhaps supposed to be a "would be" in there before the "if"?), but not enough. Entered as is. paper 02-170r2 as is paper 02-171r1 with the following changes Fixed xrefs to the now gone 7.3 at [119:7], [119:16], [126:18], [132:6], [135:4], [258:20], and [260:8]. Three of these already referenced both 7.2 and 7.3 anyway. The xrefs at [126:18] (in 7.1.4.2) and [135:4] (in 7.1.8.7) seem pretty inappropriate to me - the section says nothing useful on the subjects xrefed, but that was also true before this paper - it isn't new. Perhaps 7.3 used to have relevant material before 02-129r2, but I didn't go back to check. Someone might want to improve these 2 xrefs. paper 02-173 with the following changes 2nd edit deletes from ", with" instead of from ", which". 3rd edit not done. This is descriptive, not prescriptive, so "which" is correct. This isn't telling us what entity is involved; it is saying something about the entity. Note the almost identical wording at [165:11]. If we are going to use the wrong word here, we should at least do so consistently. But I added a comma for consistency with [165:11]. paper 02-174r2 with the following changes I assume the intended LaTexism is \mindex instead of \index; we don't use \index directly. And the embedding of LaTeXisms in LaTeX got garbled between 02-174 and 02-174r2. I did what was meant. I cannot fathom what sense it makes to make an index entry for "suitable generic interface". The phrase doesn't even mean anything without the qualification of what it is suitable for. Sitting in the index, it doesn't have that qualification. I can't imagine anyone looking under "suitable generic interface" in the index anyway, but in the unlikely event that they do, I'd expect them to be surprised that apparently the only thing generic interfaces are suitable for is derived type I/O. Did the original author perhaps forget that tdef puts entries in the index (it's his macro, so I'd think he would know), or does anyone actually think this a reasonable index entry? Done as directed, but I think it is crazy. I think the "the"s inserted before are incorrect. I've made the point several times that bnf terms are like proper nouns and normally do not take articles, except where one is needed for clarification (or to avoid starting a sentence with lower case). Note that the basic form of a bnf definition goes " is definition"; it doesn't go "A is definition". Wouldn't surprise me if I've made the point about these specific instances. But if Van is going to keep adding them in, and J3 is going to pass them I guess I'll just do what I'm told. I think the various elaborations of "specified" are wordy, doubly redundant (yes, I mean each of them has two separate redundancies), and inferior to what they replaced. But again, you've got what was passed. I hate to mention the other 16 occurances of the same phrasing that grep finds. But though I'm not going to reject the edits passed by J3, neither am I going to take it on my own initiative to compound what I consider to be a mistake. Hmm. I'm not even sure that the above elaborations are actually technically correct. Can become defined? I think is a letter followed by 0 to 30 letters, digits, and underscores. A scalar integer variable can become defined, but I'm not so sure about . Perhaps I don't want to think too much about that because I'm sure we do comparable things all over. paper 02-175 as is paper 02-177r1 as is paper 02-178r2 as is paper 02-179 as is paper 02-180 as is paper 02-181r4 with the following changes Set "flush" in all caps in subclause title. Added a few token index entries. Added appropriate syntax numbers to the beginning of all the constraints. These do apply to specific syntax rules only. "list" -> "" in the 2nd constraint. Otherwise, it lacks adequate context. See similar constraint in 9.7. ISO will have a cow if they notice us saying "section", so let's not exacerbate the problem. Just "9.9" instead of "section 9.9". I have no preference on "are described in" vs "are as described in", but the otherwise identical sentence elsewhere omits the "as", so let's do so here also. Added a serial comma. Hmm. What is the difference between "processor-specified" and "processor-dependent"? Grep finds no other instances of "processor-specified" in the whole draft. I'll leave this for J3 to fix, but I bet they will want to. The normative text about negative IOSTAT values doesn't parse sensibly. I'm also suspicious that you want the processor to set IOSTAT to only one of positive, zero, *OR* negative, instead of to all three simultaneously. Left to J3 to reword. I forsee an interp question about what it means for a flush operation to "have no effect". Does that mean that if there is no data to flush, you get a non-zero iostat? That would surprise me. That's not only harmless 0 it doesn't seem abnormal at all. I'd say it was much like rewinding a unit that was already rewound. For that matter, since flush is one of several I/O statements allowed on units that do not exist, why is it treated differently from all the others. We don't get a non-zero IOSTAT for a rewind of a non-existant unit, so why should we get one for a flush of a non-existant unit (as it appears to me we do.) I think that the whole business about negative IOSTAT values here is a mistake. It is making flush special in a way that it isn't really any different from some other operations. I'm dubious of the merits of adding completely new features at this late date at all. But if they are added, it seems to me that they should be done with as little impact as possible. This "harmless condition" business is something that has interactions with other statements in that it wil seem anomalous to have it here and not for comparable situations in other statements. Plus, I think it ill-defined. I believe that adding this oddity to FLUSH jeopardizes the whole FLUSH proposal and reinforces my opinion that even small features like FLUSH need more thought than they get when added at such a late date. paper 02-184r1 with the following changes I omitted the last sentence of the edit, except for the xref, which I combined with the preceeding xref. The sentence wasn't technically correct and anyway didn't directly relate to storage sequence. A derived type that is not interoperable is not allowed to have the BIND attribute at all (or, if you take John's definition, the BIND attribute is what makes it interoperable). Seemed easiest to just delete the sentence and let the xref do the talking. The preceeding sentence said what was really needed here anyway. paper 02-185r2 with the following changes The editor finds it difficult to even parse the sentences in this paper. I completely gave up on any attempt to figure out the technical meaning. I can't even follow the allegedly helpful note. Perhaps it is just me. I hope that whatever this paper says is correct. I made no attempt to rewrite it. I don't understand what it is trying to say well enough to make such an attempt, even if was appropriate. If J3 didn't want these words in the standard, then they shouldn't have passed it. This includes the "non-passed-object" term that the paper explicitly suggests the editor might rewrite, but which he declines to do. I did eventually manage to hack the LaTeX to get the [397:34-36] edit as specified, but the reason I had to hack it is that the construct is being misused. Oh well. I presume that 398:38,39 is a typo for 397:38,39. Ok, I did fix the "a effective" to read "an effective" as shown in the "cumulative effect", though not in the edits. paper 02-186r1 parts 1 and 2a as is paper 02-187r2 with the following changes I don't understand what the "also" in the new para is supposed to be saying. Entered as is. Hmm. Interp question raised when I was trying to figure out what the "only" meant. Is it allowed to specify the same name multiple times in the s of an interface body? I presume that 400:25 is a typo for 400:35. paper 02-188r2 with the following changes [43:20-21] Paper 02-184r1 also edited this same material, making this edit moot (those words aren't here at all). [64:23] Presumably you meant (italic) instead of <> (bold). Bold makes no sense here. [87:6-11] See unresolved issue 367. [381:14-16] Deleted an "and" and added a comma to make a well formed list. [391:13-392:1] See unresolved issue 368. [421:7+] This is acually a definition of "interoperability" rather than "interoperable". "Interoperable" is not a property; it isn't the right form of speech. ("Property" is a noun; "interoperable" is an adjective.) But the definition seems to be sensitive enough that I don't want to just craft my own. paper 02-189r2 with the following changes It seems to be that the first edit makes the normative text directly contradict Note 5.25. After all, note 5.25 was there to explain the material that just changed. The material changed, but the explanation didn't. Why would volatility of the target be any reason to declare the pointer volatile if such volatility applies only to the association? If this isn't a direct contradition, then I misunderstand the normative text, the note, or both. And I don't see how the new note 5.25a is supported by the text. In particular, I don't see how reloading the address necessarily has the effect of treating the object as volatile. Entered all edits as specified...(later) except that I removed the hyphen from "non-volatile". paper 02-190 with the following comments I expressed my disagreement with this in pre-meeting email. I think it confusing and ambiguous in that most contexts pertain in some way to the target. Apparently J3 disagrees. So be it. Entered as is; comes with corresponding warranty on interps. paper 02-191r3 as is paper 02-192 with the following changes At first I did these all, but then decided I disagreed with the last 2 and undid them. Those two are not in mathematical expressions - they are illustrating usage in Fortran code. Note, for example, the ** in the same table. (I did fix the spacing before the **, while I was there). paper 02-193r1 with the following changes [xi] Fixing the table numbers also fixed this. (There aren't 15 tables in section 13). Um... well it fixed this when I reput the table number fix back in after it was overwritten. [147:40] Yes, the hyphenation happens by "magic". I can override it, though my dictionary shows both places as acceptable. Ok, I'll do so. Makes the line a little "tight", but not unacceptably. paper 02-194 as is paper 02-195 with the following changes Did items 1 and 2. Also changed pg xiv to correspond to the changes of items 1 and 2. The (cont) suggested by item (3) seems like a good idea, but is likely hard. Will leave that to Van if he can figure out how. For my own part, I found the missing lines to look more like a bug or display artifact than a continuation indication; I didn't actually realize they were intentional until I was told. Still, they are certainly acceptable if that's what the committee wants and if Van can figure out how - I don't think I can with acceptable effort and time. The previous macros did notes an entirely different way that had lots of undesirable side effects. (And going back to them would require a lot of work in redoing pretty much all of the notes to reintroduce the hacks needed by those macros. CVS would help in such resurection, but it would still be a lot of work). I'm not 100% sure exactly what is wanted for item 4. I can make some reasonable guesses, but I assume someone must have some specific ideas. I'll probably leave this to Van, who is more expert in LaTeX indexing than I am. If he does it prior to release, I may redo this para, but I'll leave it for the record for now. paper 02-196 as is paper 02-197 with the following comment In other days, I might have rewritten the last phrase of the note so that it actually fits in the grammar of the sentence, but I've entered it as is. If "they might be...the problem eliminated..." makes sense to the rest of J3, then I guess it must be ok with me. I find its point to be confusing anyway; fixing the grammar won't fix that. Why would anyone even think that a message or status would be automatically passed up more than one level? There is is user code involved, which of course can do pretty much anything it wants with the data. It isn't going to get passed up another level unless the user code actively does so; I find it confusing to suggest otherwise. paper 02-198r1 as is paper 02-199 with the following comment I disgree with much of this paper...so I guess I'll just put the whole thing in as is rather than trying to second-guess J3. The old title was inclusive, as interface bodies are always in interface blocks. Additionally, the new title stands out as using plural forms amidst all the singular titles around it. I don't see how the old words neglected the module procedure statement (it's presence did specify something about the form of reference by which the procedure could be invoked). But I don't see how the new words say anything different, so I guess that's ok other than making me wonder what it was supposed to be about. I can't figure out what the second sentence of the edit is trying to say at all. It is the whole interface body that specifies the interface; the name alone doesn't specify it. I suppose this might be referring to the procedure statement, but if so it is out of place and incomplete - or perhaps just inconsistent with the same author's paper 02-166r2, which allows many things other than an interface body name in that role. paper 02-202r1 with the following changes [28:23-29:1] "is a not" -> "is not a" (cearly a typo) The explanation of "all for consistency" confused me in regards to "following the" -> "following that" because there is no occurance of "following that" anywhere else in the whole c03. On brief consideration, I realized that the "following that" is more precise and perhaps *OUGHT* to have also been said in the non-character case. So to indeed make it consistent, I changed "following the" -> "following that" on [28:18]. Doing the "data type" -> "type" edits, I noticed a few cases of "data value" and wondered what the difference between a "data value" and a "value" was, but I didn't do anything about it. Also changed "data type" instances on 34:9, 40:17, 43:7, 63:9->63:29, 343:16, 343:22 [344:3-5] And 344:10 while I'm there. I note that we still have IEEE_DATATYPE and IEEE_SUPPORT_DATATYPE, but those would be language changes (and in the TR even) instead of just editorial ones. Otherwise, the excuse to shorten those long names would be welcome. paper 02-203r2 with the following changes Note that it was not at first obvious to me what "paper 205" referred to. It is fine to use short forms like that, but please give a hint somewhere when you do so. This paper doesn't show any of the typographical markup (italics). I could guess most of it, and I used the corrigendum as a check. ...later..Oh, I see. The paper was done in word. Don't expect the editor to look at word documents. Please output PostScript copies of word documents in cases where typography matters. The text of the note from paper 02-205 confuses objects and their names, but I entered it as is anyway. No kind of name is an object, regardless of whether it is a , a , or anything else. Likewise, there is never a reference to a , only to the type parameter. [147:21+] There is no such bnf term as in f2k. I hope you meant as that's what I put. (I also deleted the article as long as I was fixing this anyway, though since Van seems to like articles with bnf terms, I suppose someone might add it back in). I suppose the other possibility is that you meant "the target" (no italics) instead of "". That would also be ok, but "the " is not. [251:1,4] These two paras seem awfully loosely written. It isn't clear what module and what procedures are being referred to. By an extreme reading, every implicit-interface procedure has to be explicitly declared in every module (regardless of whether it otherwise has anything to do with the module). By a reading that someone might actually believe, but still not what I think was actually intended, this makes it illegal to do module one real, external, public :: f end module one module two use one end module two because module two does not have explicit external or type declarations for f. The para in question is quite specific that the type declaration has to be from a type declaration statement in the same scoping unit. There is certainly no type declaration statement in the scoping unit of module two. I'm sure that there is *LOTS* of code that violates this reading. This is also a strange and obscure place for these paras. Their connection with the USE statement was tenuous before, and has all but disappeared by now. These are just requirements on modules, so 11.2.0 seems appropriate, not 11.2.2. But this isn't new to 02-203r2, or even to corrigendum 1. It appears in the original f95, probably from one of the f90 interps, though I didn't trace back that far. Entered as is. [343:37] Retch. But I suppose a native speaker of whatever language this is from might think it reads well. [274:44] removed the hyphen from "non-elemental" in accord with the style used in f2k (which also appears to be the more accepted English style). paper 02-204r1 with the following changes People might want to give special attention to checking my work on this paper. It had a lot of small edits all over the document, so the odds of my skipping over one by accident are probably higher than normal. Plus, being from interps, these are presumed to be edits of some importance. The same might apply to paper 02-203r2 except that it had fewer edits for me to apply. [61:10-12] See unresolved issue 369 [67:9+] I took the "+" as implying a new para (which does seem appropriate). [72:26] See unresolved issue 370 [334:33+] I think this would be better with "MOLD" instead of "The optional argument". All other text here in f2k refers to MOLD by name, whereas the text in f95 didn't. Using the name MOLD avoids possible confusions. But I entered it as is. I took the "+" in this case as not implying a new para. Please be more explicit. [129:19] This is pretty abysmal to parse if you don't know what it is saying before you try to read it, but that is a failing of the interp edit rather than of this paper. [150:23+] Subscripted the c in as in the corrigendum and the preceding para. Included the period at the sentence end. [219:22+] I am completely mystified as to why this para was put in a separate section instead of added to the existing 9.10. Seems to me that it is just one case of a restriction on input/output statements. I don't see anything that particularly distinguishes it from the other restrictions in the old 9.10. But this seems so obvious that I assume J3 must have noticed it and consciously decided to add the new section, so I did it as directed. The commas in the added sentence are grammatically questionable and jarring. They are pretty clearly hacks to rescue a sentence that is hard to parse without them. They almost make the "or...unit" look like an appositive (which it isn't). Entered as is. Nowhere in the draft except in this new note do we use "restrictions in"; we use "restrictions on" instead. Entered as is. Not directly related, I note that the section title of the old 9.10 has "restriction" in singular even though there are clearly multiple restrictions in it. In f95 there was only one restriction. I suspect that we just failed to notice the singular title when we moved/added material here. I'd have just changed this as an editorial fix except that the addition of the new restriction as a separate section makes me unable to figure out what an appropriate title is - just changing "restriction" to plural no longer seems to reasonably delineate this section. [262:5] I'm often dubious of things expressed in terms of specific syntax. In this case, I'm not sure why the restriction applies only to the external statement and not to the external attribute on a type declaration statement, but if this is a problem, then it is in the interp instead of in this paper. Perhaps the other cases are covered elsewhere. [270:23-25] I don't understand the bolding here, but it does seem to be what the passed interp says. Bold indicates a definition, but here we bold "present" when saying what it is not instead of what it is. Oh well. P.S. We have been using double angle brackets in text to indicate bold: <> instead of *present*. [286:18] The phrase "associated array variables all of whose corresponding elements are associated" has more uses of the word "associated" than I can figure out independent meanings for. But it was that way in the interp. Entered as is. Interp 9 - Yes, the section corresponding to 13.6 in f95 no longer exists, but the TRANSFER intrinsic does. This needs to be said somewhere...or we'll just have the same interp come back for f2k. My original comments about 01-288 (which was the paper passing this interp) said ok, but I'd think it better if similar words were added to the detailed description of transfer (13.14.110) instead of to the waffle (which formerly said nothing and is deleted in the f2k draft). I recall being "promised" that an appropriate new "home" for this would be found in f2k. Perhaps I should have gotten the "promise" in writing. :-( paper 02-205r2 with the following comments I could read the para from the corrigendum. The version in this paper appears to follow the philosophy that nobody will be able to claim that it is in error if they can't figure out what it says. That doesn't strike me as a good way to do standards, but you've got what you passed. Entered as is.