J3/99-138 Date: 29 Apr 1999 To: J3 From: R. Maine Subject: Changes to list of unresolved issues. The following are changes made to the list of unresolved issues. These changes are reflected in 99-011R1 and in the J3 notes of 99-007R1. These changes add 80 new issues and resolve 41. This makes a total of 201 issues, 64 of which have been resolved, and 137 of which remain. Yes, we went 39 issues in the wrong direction. I believe that this partly reflects the fact that we are still doing major work on adding new material, some of which even involves substantial new issues of specification. It also reflects the fact that the editor's tolerance on how much work he is willing/able to do to fix up things is dropping. So some things that he might have once tried to fix are instead just getting flagged as in need of fixing. Expect this tolerance to continue dropping - the editor has a new day job assignment that will majorly lower the amount of time he can afford to spend on J3 work. I. RESOLVED issues paper 99-104r2, errmsg Resolved 116 and 117 (by deleting the area, thus making them moot). paper 99-105r2, standard unit numbers Resolved 63. paper 99-106r2, allocatable fixes Resolved 72, 74, 75, and 81. paper 99-108r1, initial/final Resolved 7 and 66. paper 99-110r1, formatted stream Resolved 68. paper 99-114, unresolved issues 71 and 84 Resolved 71 and 84 (as you might guess from its title). paper 99-115r1, J3 notes in c9-10 Resolved 1, 4, 8, 23, 25, 28, 29, 31, 65, 69, and 70. paper 99-117r2, interop glossary Resolved 92. paper 99-118r1, procedure interop Resolved 85, 91, 93, 95, 96, 98, 99, 103-105, 108, 111, 113, and 114. paper 99-119r1, issues 73, 77, 80 Resolved 73 and 80. paper 99-108r1, initial/final Resolved 66. II. CHANGED UNRESOLVED issues paper 99-112, extra characters Issue 119 - brackets for array constructors Although the paper didn't explicitly say so, it clearly resolves the "P.S." part of this issue, where it was noted that the extra characters had not yet been added to the character set. I deleted that part of the issue. Left the rest, with the following additional para: The specs and edits papers for adding the brackets to the character set say that "No semantics are assigned to these characters." It has been (somewhat emphatically) pointed out to me that this could be interpreted as resolving this issue by saying that we aren't going to do it. It is unclear to me whether this is the intention or not. I had been interpreting that statement more as a separation of the question than as a resolution. Given the apparent differences in opinion, I'd like specific J3 direction on whether to remove this issue. In general, if papers are meant to resolve issues, please say so explicitly in the paper. papers 99-105, 99-107, and 99-115 Issue 64 - ROUND= for unit * Added the words suggested at 180:30 by paper 99-107. Also added the following para: We now have unit numbers for *, resolving issue 63. Paper 99-115 says that "could" address issue 64, but we haven't had any formal action saying the issue is, in fact, resolved. paper 99-115r1, issues in c9-10 Issue 3 - I/O error handling On further study, I'm still confused by part of this issue. Why do the 2 lists in 9.5.4 not mention the transfer of control per end=, err=, and eor=? They do mention setting the IOSTAT variable. There also seems to be some inconsistency in descriptive models between 9.5.4 and 9.9. The lists in 9.5.4 explicitly include positioning after data transfer and setting of IOSTAT= as part of "executing...i/o statement"; they do not include transfer of control. However, 9.9 says that when errors happen, "execution of the statement terminates" and then several things happen; these things include file positioning, setting IOSTAT and SIZE variables, and transferring control. I think I'm being confused here by talking about the error handling as though it were not part of the execution of the statement, when clearly it is. Perhaps what is being talked about here is the "normal" (but that's not quite the right term) execution of the statement. Then it would nake sense to say that this "normal" execution terminates and the special handling (or whatever it is called) begins. If so, the definition of IOSTAT described in the lists in 9.5.4 is always defining its value to be zero; any non-zero values are set as part of the error handling described in 9.9. I think that holds together. Perhaps my previous suggestion about saying that we skip steps 4-8 was a poor idea. Instead, go back to saying that execution terminates. The question is then "execution of what?". Its not execution of the statement because there is still stuff left to do. Instead, its the execution of just the things listed in 9.5.4 that is terminated; the stuff in 9.9 is still to do. Whatever it ends up saying, section 9.9 should probably use simillar terms. Perhaps the title of 9.5.4 is misleading also, though I'm not sure about that. Issue 30 - ROUND= integration with DTIO The first part of the issue (the part about ROUND=) was adequately addressed. But nothing was done about the rest. I moved the note to 10.6.4 and replaced its body with The material on edit descriptors in 10.6.x appears inadequately integrated with derived type I/O. Those edit descriptors that have "state", talk about the state at the beginning of execution of a formatted I/O statement. These descriptions do not appear to be correct for child data transfer statements if I am interpreting 9.5.4.4 correctly. And if I'm not, then perhaps that section isn't as explicit on the subject as it needs to be. Hmm... Now I'm not certain which way was intended. Anyway, I noticed this problem in the descriptions of P, BN, BZ, RU, RD, RN, RZ, S, SP, SS, DC, and DP in sections 10.6.x. If those sections are ok, then a few more words on the subject in 9.5.4.4 are in order. paper 99-116r1, enums Issue 115 - enums Deleted the whole body of the issue and replaced it with: I'm not sure how to interpret the statement about interoperability in the first para of 4.7. It uses the term "may", which indicates permission. Is this a permission or a requirement? If it is a requirement, is it one on the processor or the program? Section 1.6 says that requirements apply to programs except where stated otherwise. The statement also seems a bit vague about details, since there can be multiple enumerations that don't interoperate with each other. All in all, I'm not sure exactly what normative point the statement is trying to make. Perhsps it is just intended as a statement of explanation of a possible use, without actually saying anything normative. In that case, it might be more appropriate as a note. If it does stay as normative text and isn't meant to specify a requirement or permission of the standard, then don't use terminology like "may". paper 99-119r1, issues 73, 77, 80 Issue 9 - initialization of objects with allocatable components I added the following para to the issue 9 text (in section 5.1). Paper 99-119 added restrictions in this area to constant expressions simillar to the restrictions on initialization expressions. This appears to be moving in a direction opposite that suggested by this issue. Whereas that is fine if that reflects the majority desire, I get the feeling that the change was done without noticing this issue at all. The paper didn't, after all, say to delete issue 9 as resolved in the negative. Of course, its also true that constant expressions don't get used very many places, (particularly after initialization expressions were decoupled from constant expressions) so I'm having a little trouble seeing exactly where this would apply anyway. Issue 77 - restricted exprs I deleted the former 2nd para of issue 77 as resolved, but added the following in its place. Paper 99-119 resolved the former 2nd part of this issue. It claims to have also added some requirements to address the first para, but I don't see edits for the claimed additions. The requirement alluded to is the one in the sentence imediately preceding this J3 note. There are simillar sentences for constant expressions and initialization expressions, but no mention of type parameters in those cases. I conclude that a type parameter in a constant or initialization expression can be an arbitrary, run-time expression. Note that the decoupling of constant and initialization expressions does not get you out of the requirement to say something about type parameters there - I'll claim that if you don't see why, that you haven't thought it through (or that I'm confused). paper 99-106r2, allocated fixups Issue 16 - procedure declaration stmt I disagree that the first para is covered. This is at least the 2nd, if not the 3rd, time that claim has been made, but I still disagree. Added following as a second para to elaborate: The material at 12.3.2.1 in the para before note 12.4 needs work anyway because its reference to the procedure body makes no sense for dummy procedures and abstract interfaces. What procedure is this talking about for abstract interfaces? How does this turn into a restriction on the procedure statement? Even if you could argue that it should apply, it is in the wrong place. If a procedure statement assigns an abstract interface to a procedure that doesn't match, the problem is not in the abstract interface; it is still a perfectly valid abstract interface. The problem would be in the procedure statement. We need something in the section on the procedure statement about this. The last para is resolved, but replaced it with this new one: The meaning specified for the case where proc-interface is absent is a specification and syntax change from 97-218r2, which said that this case meant an implicit interface subroutine and that there was no way to use the PROCEDURE statement to identify a procedure that was ambiguous as to whether it was a function or subroutine. The current version allows the ambiguous case, but leaves no way to specify an implicit interface subroutine. This reversal seems strange. I don't see this spec and syntax change mentioned in the intro to 99-106r2, making me wonder whether or not it was intentional. If we change this back, then it becomes redundant that the current constraint about deferred type params has a condition on proc-interface being present - it would always have to be present for functions. Issue 76 - type parameter syntax in allocate Deleted all the old body of issue 76 and replaced it with: Paper 99-106r2 addressed most of the previous version of this unresolved issue. The approach taken leaves two questions in my mind. The biggest question is whether the para in question (the one in 6.4.1 beginning with "For derived types") is needed at all. Does this para say anything that isn't implicit in the bnf term type-spec? I don't think so. The smaller question is that if the para stays (which I recommend against), then perhaps it needs to also say something about the case of type aliases, where the assignment of values to type parameters is done in the type alias statement. Oh yes. And also the para doesn't have anything explicit to say that its the type-spec that it is talking about. But all of this small stuff is moot if the para is just deleted. Issue 78 - assumed type parameters in pointer assignment Deleted all the old body of issue 78 and replaced it with: The above para on assuming type parameters in pointer assignment switches between dynamic and declared parameters without explicit clue about which is meant when. I assume that the phrase "corresponding parameters of target" means the dynamic values in the 2nd sentence, but the declared values in the 3rd. But nothing really tells me this. I don't think the 3rd sentence makes sense if its not the declared values, but the 2nd sentence might make sense as declared values. Also, not entirely related. I find the phrase (used several times in section 7.5.2) "if pointer-object is a data object or function procedure pointer" to be quite a mouthful and hard to figure out. Took me a while to figure out that the other option was a subroutine procedure pointer (ok, I'm slow) and that thus the whole point of the condition was just "if pointer-object has a type". Might it not more simply be expressed that way? In some cases, I'm not really sure the qualification is needed at all. If it doesn't have a type, then there will be no type parameters, so all the restrictions about type parameters are moot; I think you can stil leave the restrictions and just say that they apply to all the type parameters that exist (none). Issue 79 - dummy arg type parameters Deleted all the old body of issue 79 and replaced it with: Section 12.4.1.2 discusses deferred and assumed type parameters for dummy arguments that are not INTENT(OUT). This natually leads me to wonder where anything is said about the INTENT(OUT) case. For assumed character length, we assume the length regardless of intent. I'd presume we would want other cases of assumed type params to work that way, but I don't see where we say it. For deferred, things are more complicated - maybe its ok, but I'm not sure. Also, how do we assume values from the actual in cases where the actual has no values (as in when it is a disassociated pointer)? Say... And where do we ever say that any changes in the deferred type parameter values of the dummy argument get passed back to the actual? There are a lot of words about what happens with pointer dummies on return but I don't see that these explicitly cover the type parameters. I presume that a pointer better end up with the same type parameters as what its pointing to, but I don't see a global rule about this. (The actual arg isn't the pointer-object of a pointer assignment statement, so all that bit doesn't apply). paper 99-118r1, procedure interop Issue 83 - C standard ref I added the following extra sentence to issue 83 in 1.8: We refer to it elsewhere as "the C standard", so we should also establish that terminology in 1.8. Issue 100 - incomplete type Instead of deleting issue 100 and then adding a new related issue in the same place, I kept the number and just replaced its body with the new material suggested in 99-118r1. P.S. I'm minorly amused to hear that the C9x standard formally uses the term "flexible member". I hadn't heard that one before, but I have a strange suspicion that I will hear it alluded to in ways not envisioned by the standard. :-) Issue 120 - C strings Note 16.1 answers the request to say at least something about C strings. It leaves me with one question, however. (Particularly when I was trying to think of cases to counter its proposed wording that it was now "a simple matter" to argument associate a Fortran character string with a C string. I didn't notice a restriction against assumed-length character dummy arguments for procedure interoperability. Perhaps I just missed it (which is quite possible - I'm skimming). Without such a restriction, we could declare such a Fortran procedure with BIND(C) and I wouldn't know how to actually call it portably from C. Issue 101 - struct interop example I deleted the old body and replaced it with. Note 16.5 looks substantially better than it used to. However, I think it a bit odd that it now seems to imply that BIND(C) in a derived type definition automatically makes the ISO_C_BINDING module accessible. Issue 106 - C reference type I deleted the old body and replaced it with. The first sentence of 16.2.5 is now much more plausible looking as a definition of the term "reference type". But it still seems completely out of place. I can see that such a definition is needed in the section on C functions, but not as the introductory sentence. This just isn't much of an introduction to C functions. III. NEW UNRESOLVED issues. paper 99-104r2, errmsg Issue 122 - eof and eor in dtio procedures In 9.5.4.4.3 on dtio, we have one para that says that the values returned for the err, eof, and err arguments determine whether the corresponding conditions are triggered in the parent data transfer statement. Why then, do we feel obligated to say, 2 paragraphs later, how a true value for err interacts with err= and iostat= specifiers in the parent i/o statement? Isn't that completely specified by saying that an error condition is triggered? If not, why don't we have to say something simillar about eof and eor? And if the parent i/o statement is async, I suspect that the err= and iostat= specifiers in the statement that does the corresponding wait operation might be as relevant as the specifiers on the parent i/o statement. We should do in standard writing the same thing that we presumably do in code design - modularize it. The definition of what the dtio procedures do should not be talking about how errors are handled in i/o statements; that is covered elsewhere. And the dtio procedures *CERTAINLY* shouldn't be dependent on the syntax details of such error handling. All we should say here is the stuff in the first-mentioned para - that the conditions are triggered. The only possibly useful thing that I can see is added by the second-mentioned para is the bit about how errmsg is made available if the program terminates. That might be kept, but abstracted from the details of what syntax in the parent i/o statement might cause termination. Another issue that I'll combine here instead of numbering separately. As written, it is quite explicit that the dtio procedure is not allowed to use errmsg to explain eof and eor conditions; it is only for err conditions. Is this intended? This does not correspond to what the parent i/o statement is expected to return in its errmsg-variable. And it means that the procedure could not just pass its errmsg argument along as the errmsg-variable of a recursive read that might get an eor or eof condition. This sounds p[roblematic to me; I'm betting it is an oversight rather than intentional. Issue 123 - errmsg for non-errors (In 9.9.2) Since errmsg is used for messages about conditions that are not errors (eof and eor), perhaps its name is not the most appropriate. I might suggest just "message" or "msg". This applies to the ERRMSG= specifier, the errmsg-variable bnf term, and the errmsg dummy argument in dtio procedures. Issue 124 - i/o restriction wording In 9.10, the restriction relating to variables that may become defined or undefined needs a lot of work that I haven't done. I entered it pretty much as is. The phrase "or any associated entity" doesn't say what we want. (Could be read to mean any entity associated with anything). And the commas aren't appropriate by strict grammatical rules (but they are needed for clarity, which is sometimes an adequate justification to stretch the rules). A variable might "appear" in a specifier, which is a piece of syntax, but I don't think it can "appear" in an entity. And a specifier might depend on the value of a variable without the variable appearing in it (for example, if the specifier references a function that gets the variable from common). Need something more like that all those other things can't be affected by it or depend on it (which would also handle the associated bit). Watch out for the other way; the specifiers like SIZE= do depend on the io-list in some sense (though things like subscripts in SIZE= better not). Look at the 106:18-22 area for guidance. What does it mean to talk about "an entity in a do-variable"? The deleted wording at 180:16-22 of 99-007 might have been a bit awkward, but part of that was to avoid things like this that make no sense. And how can we talk about "the same data transfer statement" for things that are supposed to apply to some statements that aren't data transfer statements? Yes, I know much of this was that way before, but its still poor. Instead of deleting the previous material on this area, as instructed in the paper as passed, I have moved it to the 3 paras following this J3 note. This is to make it convenient to find the old words and perhaps craft something that uses the best parts of the old and the new. We presumably won't want to keep both the preceeding para and the following 3. paper 99-105r2, standard unit numbers Issue 125 - inquire on internal files Where do we now prohibit inquire on internal files? In f95, there was no syntax for doing so. With dtio, there is now a syntax (because we can now sometimes have a unit number for an internal file), but I thought the intention was to prohibit such inquiry. In 99-007, this was done by the prohibition (in 9.4) against negative unit numbers, along with the specification that dtio would use negative numbers for internal files. However, that prohibition was expressed too broadly, also prohibiting the recursive reads/writes that dtio needs to allow. Looks to me like it was fixed to allow the reads/writes, but now also allows INQUIRE, which I don't think was intended. If we do allow INQUIRE on internal files, we better make sure that it all makes sense, which might be possible, but I don't think we want to bother. Note that I see no problem at all with INQUIRE on standard input/output/error; indeed it can be quite useful. I believe that the only reason it was disallowed in f90 was that the unit * would have been ambiguous and we didn't have unit numbers corresponding to *. Note 9.42 suggests that you need a positive unit number for INQUIRE, but I don't know where the text supports this. Also, the note's statement that one should check for a postive value fails to allow for negative standard unit numbers. paper 99-104r2, formatted stream I/O Issue 126 - position in formatted stream files I don't think that the wording of item (5) in the properties of formatted stream access files in 9.2.2.3 is acceptable (and I see that Henry also said he didn't like the wording of "remembered"), but I'll skip trying to fix it for now. As long as I'm writing a J3 note here anyway, I'll suggest that it might be worth an informative note to explain item (4) - namely to say that the position number might do funny things accross a record marker. I assume that we don't treally expect postion numbers to be completely arbitrary. Presumably we expect them to increment in the obvious way within a record, even if we disallow positioning to all those points? Or maybe not. Perhaps we just leave it arbitrary. I'd think some people might find that confusing, though. And if its that arbitrary, I'd be concerned that we might not get the desired C interopability. Of course, that's not necessarily given for unformatted streams either unless we say something explicit. Hopefully the C interop section will have something on that. Yes, this note rambles. Issue 127 - end-of-file in formatted stream files I'm not convinced that end-of-file conditions are fully covered for formatted streams. Note that there is no endfile record in a formatted stream (and I doubt we want there to be one). A strict reading of the 2nd sentence of 9.2.3.2 would tell me that it didn't apply because the endfile wasn't as a result of reading an endfile record, but that's subtle. I'd suggest explicitly adding something about sequential; didn't do that myself in case someone thinks that this should apply. What happens when reading a partial record at the end of a file? We say that there may be partial records, but I don't see where we ever say what the effects of such a thing are. If there is a partial record at the end of a file, is it possible to position after it so that it is the previous record? Should, perhaps, reading past the end of a partial record be an error instead of an eor or eof condition? Does padding apply to partial records? Some of these questions are probably best answered elsewhere than in 9.2.3.2, but I'll lump them all into one J3 note. Issue 128 - empty incomplete record The words in 10.5.3 about linefeeds in A output imply to me that a non-advancing formatted stream output statement that writes a linefeed as the last character in a stream file will cause there to be an empty and incomplete record at the end of the file. Is this empty incomplete record supposed to be distinguishable from having no record? If so, I wonder how unix-like systems are supposed to distinguish it. If not, I wonder whether we have it described correctly. Same with / editing, where this was copied from. These holes leave me unconvinced that the description of record handling "just works" with formatted stream i/o. This related to unresolved issue 127 about handing of incomplete records. misc, not from a current paper Issue 129 - reference for ISO 10646. We cite ISO 10646 in selected_char_kind, but I don't see it in the reference list. Speaking of selected_char_kind, it implies that an ASCII character kind must be available, but I don't see anything about that in 4.4.4, where it should be. Section 4.4.4 mentions what ASCII is, but never bothers to say anything about requiring it to be available. And 4.4.4 doesn't even mention 10646. Buried in an intrinsic in section 13 is not the place to define what character sets are supported. That material belongs in 4.4.4. The intrinsic is just a means of finding the kind numbers. Note that we don't use selected_real_kind to define what real kinds are available. Issue 139 - shall not be defined I don't know what the para in 6.0 after R608 is trying to say. It has 2 cases of "shall not be defined". The "shall not" bit reads like a requirement, but I don't understand what the program is being required to do. Hmm. Perhaps it is talking about becoming defined instead of being defined. That might at least make some sense. I don't have time to track it down right now. paper 99-119r1, unresolved issues 73, 77, 80 Issue 130 - In a declaration I entered the bit about "In a declaration" from paper 99-119r1 as specified in 5.1 in the para before note 5.4. But I don't know what the phrase means. We tried several times to get a precise definition of "declaration" during f90 interps, but never suceeded. Does this mean in a type declaration statement? If so, that seems unreasonably restrictive and incompatable with f77, f90, and f95 (which allow such things in several other places - namely several attribute specification statements). Perhaps this is counting on the second sentence of 5.3. That might be ok, but I'm not entirely sure. Basically, since we don't have a precise definition of that it means to be "in a declaration", I don't like using the phrase. If we can precisely define it, then lets do so. If we can't precisely define it, then we shouldn't use the phrase. Perhaps it would be adequate to just say a type declaration or an attribute specification statement, but I'm not sure whether or not that correctly covers everything. I'll let J3 think about this one. Issue 131 - Type parameters in spec/init exprs In 7.1.6, I entered the wording about "within a derived type definition, of the derived type being defined" exactly as specified in paper 99-119. It seems to me, however, that this is a lot of words, and somewhat awkward ones, for saying something that doesn't need to be said. Type parameters have a scope of their derived type definition (see 14.1.2.5). Thus this condition is moot, since type parameters can never appear in a context that doesn't meet this condition. We don't redundantly say that the other kinds of primaries in restricted expressions can only appear in scopes where they are accessible, so why do we feel it necessary to specify this for kind parameters? I think the whole phrase in question can (and should) just be struck, but this appears to be more than an editorial question. The same comment applies to the simillar text in initialization expressions. Issue 132 - Expression classification confusions Added the text specified in 99-119r1, plus the folowing: I found the expression categorization of Fortran 90 to be very confusing. Its getting worse. We have initialization expressions, which are used in several places other than initializations, constant expressions, which aren't used much at all (alas, that term being one of the few that I can make much sense out of just from the name), restricted expressions, which are used only as an interim step in the bnf but never end up in the actual code, specification expressions, constant specification expressions (not to be confused with specification expressions that are constant; I roughly recall the distinction; does anyone else), and now restricted specification expressions. I find extra "amusement" in the observation that restricted expression is a superset of specification expression, whereas restricted specification expression is a subset (restriction) of specification expression. I guess it all makes sense in a bizarre kind of way, but it is sure confusing to imbeciles like me. Presumably I'm the only one baffled by it all. Issue 133 - User-defined operators in initialization expressions The deletion of "constant" from the definition of initialization expressions in 7.1.7 appears to me to now allow user-defined operators in initialization expressions, which I rather doubt was intentional. I could fix that up trivially, but I'll instead take this as a sign that the technical context of this edit hasn't really been adequately checked. I'm certainly not going to check it as editor. I noticed this apparent flaw without looking very hard; whether there are others or not I didn't study. paper 99-106r2, allocatable fixups Issue 134 - deferred type param specification I entered the above para in 4.3 exactly as specified. I see several problems with it. The first sentence appears to just duplicate things just said in the imediately preceding para; if it adds anything new, I couldn't figure it out. The second sentence contradicts the preceding para (by showing 3 places where the value can be specified, instead of the 2 mentioned just before); perhaps if we said it once instead of twice we wouldn't have to worry about the two times agreeing. I think that second "when" in the second sentence is referring to time (the other two "whens" in the sentence clearly are, but the phrase following this "when" doesn't define a specific time. It perhaps defines a span of time (the whole time that the dummy is associated), but the context requires a specific time at which the action occurs. Later...does this correctly cover function pointers? Issue 135 - restrictions on * and : type-param-values. I'm not sure what purpose paper 99-106r2 had in mind in rewriting the 8th and 9th constraints in 4.5.5 (the ones about where asterisks and colons are allowed). I thought the versions in 99-007 were better in all regards. Unless I'm missing something, the new version appears to now allow them in lots of places that the old version didn't. Apparently an asterisk can be used in the declaration of a component (since that's not an entity). And both the asterisk and colon can be used in constructors and allocate statements (since those aren't declarations of anything). Looks to me like this was an attempt at wording improvement that broke the technical meaning. Note that the identical words for the colon case in 5.1.1.5 were left unchanged. Why change them here but not there. Hmm. Also I'm unsure whether 5.1.1.5 belongs to be repeating these constraints or just letting the ones from 4.5.5 apply. Its not completely clear whether the constraints on type-param-value in 4.5.5 apply to any type-param-value or just to those used in derived type specifiers. If the ones in 4.5.5 apply, we need to get the bit about * to agree (as we allow * in a few extra places for character). Since type-param-value is used for both derived and intrinsic types, it might be better to move R448 and its applicable constraints into, say, section 4.2, which is about type parameters in general, instead of 4.5.5, which is about derived types. It might then also be easier to make clear what constraints applied in all cases (put them in 4.2), what ones applied to derived type specifiers (in 4.5.5), and what constraints applied to characters (in 5.1.1.5). Issue 136 - type-param-values in constructors The 10th constraint in 4.5.5 says that type-param-values in array constructors and derived type constructors are required to be specification expressions. Why? This seems like an inappropriate restriction and appears to be a change in specification. Hmm. Actually, it looks like constructors are ok as long as they are anywhere within an ALLOCATE statement (doesn't actually have to be the part of the ALLOCATE statement that specifies the type to be allocated). Strange. The same comments apply to the same words added in 5.1.1.5. Issue 137 - * char len in allocate In 5.1.1.5, in the list of places where * can be used for a character length. As a general rule, be suspicious of any condition that just says "in an X statement." There are many places in an ALLOCATE statement where a character length parameter would be syntactically valid. Consider constructors used in expressions. I think you have only one particular use in mind. Issue 138 - deferred params of functions I can't figure out what the sentence about deferred parameters of function result types in 5.2 means. First, what exactly is the statement that "deferred parameters..have no values" supposed to mean? What would be the implication of having a value or not? Second, the second clause might imply that the determination must happen as part of invocation of the function (perhaps from the function's specified type) rather than during its execution. And in any case, I can't figure out why this material is in the section on the procedure statement. It sounds like material that should apply to deferred parameters of function result types regardless of whether a PROCEDURE statement is involved or not. Shouldn't this stuff apply to module procedures (which you never declare in a PROCEDURE statement because you'll always get the interface by using the module). I see that there are simillar words in the new note (7.47) in section 7.5.2. Odd that its normative here, but in a note there. The words in that note have simillar problems (being simillar words). Plus one more problem that it is unclear there that we are talking about type parameters. And that note also seems like the wrong place to be discussing it. The question being discussed is how to interpret deferred type parameters of function results. This has even less to do with the pointer assignment statement than it does with the PROCEDURE statement. Pointers need not even be involved. It has to do with functions and type parameters. Any other relations would seem secondary. Looks to me like the words are in 2 sections where they don't seem pertinent, but not in any sections where they do. Issue 140 - deferred type parameters What does it mean to "reference" a type parameter in 6.1.3? I don't think we use the term "reference" for such inquiries in any other context. The first sentence of 6.1.3 certainly doesn't use such terminology. Also, the parsing of the sentence before this note is ambiguous; you probably intend the "deferred type parameter of" to apply to all of the elements of the list, but this is not clear, particularly since the restriction makes sense both ways. One way is covered elsewhere and has little relevance to this section, so I assume its the other way you mean to cover here. The editor could probably fix both of these problems, but has too much other work to do. Issue 141 - undefined deferred type parameters What about cases where deferred type parameters are not currently defined? Specifically, allocatable variables that are not allocated and pointer variables that are disassociated (from a deallocate or nullify). If a pointer is disassociated, and thus has no values for its deferred type parameters, how do we interpret the requirements for agreement. Hopefully we don't just ignore all agreement requirements for the disassociated case. This applies several places; pointer assignment is just where I thought of it. Another is when a null pointer is an actual argument for a pointer dummy. We say that a function with deferred type parameters determines the parameters during execution of the function. Is there any requirement for it to do so? That is, may it return a disassociated pointer (if it was a pointer-valued function)? Issue 142 - explicit interface for assumed type parameters In 12.3.1.1, should an explicit interface be required if a dummy argument has an assumed type parameter other than a character length? I'm not sure, but the question seems worth asking. If we don't require an explcit interface, it seems to me that all non-kind type parameters of all actual arguments will always have to be passed (much like all character lengths are now), regardless of whether the subroutine ends up needing this information. Paper 99-106r2 noted that deferred type parameters are covered because they can only happen for allocatables or pointers, but I don't see anything about assumed type parameters. Issue 143 - allocatable statement Paper 99-106r2 said to change 14.6.1.3 (5) to refer to the object-name in an allocate statement. That change makes little sense in this context; the original was talking about an ALLOCATABLE statement, rather than an ALLOCATE statement. I started to treat that as a typo, until I noticed that there is no object-name in the ALLOCATABLE statement. This, in turn, made me wonder why not. Shouldn't the ALLOCATABLE statement be applicable to scalars now that we have allocatable scalars? paper 99-118r1, procedure interop Issue 144 - linking to non-C procedures I skipped over rewording the second para of the note in 2.5.10 about linking to non-C procedures. Its usage of the term "link" does not seem consistent with the definition in 12.5.3. The definition says that a procedure is linked to a C function or a Fortran subprogram. This talks about a procedure being linked to a procedure. The sentence also uses commas incorrectly, but I didn't bother with the rewording to fix that either (since it would probably just need to be redone to get the linking bit right). Issue 145 - BIND(C) has no effect? Does the sentence about BIND(C) really belong in section 2.5.10? It seems out of place. If nothing else, it would seem to need an xref for BIND(C), since the term is mentioned nowhere else in section 2 at all. I'd also question whether it was appropriate in this context to give the detailed list of things that BIND(C) can apply to. It makes it sound like specifying BIND(C) for other things might have a discernable effect in this case. Am I correct that this is supposed to be the complete list of all kinds of entities that might have BIND(C) specified? If so, it would sure seem simpler and less likely to be wrong if we just said "specifying BIND(C) for an entity" instead of feeling it necessary to list the kinds of entities possible. I'd further question whether this statement is meant to be normative. Isn't it just commenting on the consequences of other material? Or is there something extra that this actually means? I finally question whether the statement is necessarily accurate. I'm not sure whether or not it would count as a discernable effect that specifying BIND(C) can cause something to be illegal (for example, a derived type that has a component that is not BIND(C)). But I'll grant the possible interpretation that this is supposed to mean only those places where it would be legal to specify BIND(C). Even with this interpretation, do we want to *REQUIRE* that a processor not do anything different for BIND(C)? That's how I read this statement, particularly when it is in normative text. Perhaps we just mean that the processor does not necessarily need to do anything different. But suppose, for example, it wants to use a different argument passing convention or whatever in anticipation of future compatability with some other companion processor? Should we say this is non-conforming? Issue 146 - Constraint on derived type names The paper's J3 note in 4.5.1 is numbered 146. And I added the following extra para to it: The editor notes that this is a constraint, unlike the material in 14.1, so there is some effect of specifying it here. I'm less sure about whether that was the reason for doing so and why we'd want to make this particular case and not others a constraint. For example, its apparently not a constraint violation for a derived type name to be the same as the name of an accessible variable (unless I missed something - admit I didn't look very hard). Issue 147 - BIND(C) attribute for global data The paper's J3 note on this in 5.1 is numbered 147. Issue 148 - BIND(C) statement Paper 99-118r1 said to add "BIND(C) statement" to the list in 5.6. I did so, but I don't see that any such statement currently exists. Perhaps it is intended to add one as part of issue 147, but this isn't entirely obvious to me. Issue 149 - Sequence association for C_CHAR args The paper's J3 note on this in 12.4.1.2 is numbered 149. Issue 150 - BINDNAME= for abstract interfaces and dummy procs The above constraint in 12.5.2.1 disallows NAME= for abstract interfaces and dummy procedures, but it says nothing about BINDNAME=. Is this intentional? I still get confused about the distinctions, but this seems strange. Issue 151 - BIND(C) for module procedures The paper's J3 note on this in 12.5.2.1 is numbered 151. Issue 152 - NAME= on subprograms I'm completely lost as to what the constraints against NAME= for subprograms and BINDNAME= for interface bodies are about. I'll just have to hope that someone understands it better than I do. Issue 153 - binding label of a dummy proc I miss the point of even talking about the binding label of a dummy procedure. Since invoking a dummy procedure invokes its associated actual procedure, it seems to me that the binding label of the dummy isn't a very useful concept. Along the same lines, why did we go to the trouble of defining the binding label to be a characteristic of a procedure argument? I thought that the point of being a characterstic was that it was something that had to agree between actual and dummy. Here we say that the binding label alweays agrees - there is no syntax to specify a binding label for a dummy, and it always inherits the binding label of the actual. This seems like a lot to be going on for no purpose. Am I missing something? Issue 154 - binding label of a C proc I think the statement about binding labels for C functions needs a bit of work. This is one case where I don't think that the translation of C to companion processor is obvious. What about when there are multiple companion processors? What about if the companion processor is the Fortran processor itself (in which case we have a way to specify a binding label other than the procedure name)? Issue 155 - multiple names in BIND(C) Are there any constraints against multiple occurances of NAME= and BINDNAME= in a bind-spec-list in a BIND(C)? I see no suchconstraints. Note that a BIND(C) is a single prefix-spec even if it has multiple specifiers in its bind-spec-list, so the constraint against multiple occurances of a prefix-spec doesn't apply. I thought I recalled some discussion to the effect that there could be multiple specifications of BINDNAME=, but only a single NAME=. Either I misrecall or this distinction didn't make it into the edits (or I failed to find it). See also issue 156 before spending too much time on this question; some possible resolutions of that issue might make this one much simpler. Issue 156 - usefulness of BINDNAME= If the meaning of BINDNAME= is processor dependent, does it achieve anything useful to standardize its spelling? I don't see how it can be used portably. Even with the note explaining a possible application, there are not enough specifics to write code that is reasonably likely to use it portably. I just find it a source of confusion. And if its meaning is really processor dependent, then I don't understand why some of the strange constraints on its use. For example, it can't be specified on an interface body. Why not? Might not the processor give it a meaning that makes sense for an interface body? I question whether this should be in the standard at all. See also related questions in unresolved issues 150, 152, 155, and 158. Issue 157 - Binding labels needed for Fortran names? I question that the last sentence of Note 12.35 (on binding labels) means what it says. For three decades I have had programs that "refer to a procedure using a Fortran name". I've not noticed binding labels as having been necessary to do this. Admitedly, when I'm writing C code, it is somewhat trickier to refer to Fortran names. And when I'm writing Fortran code, it mak be even more tricky to refer to C names. But this sentence doesn't specify any such context. Issue 158 - "May" implies permission I'm dubious that the usage of the word "may" is correct in note 12.36 about BINDNAME=. I could perhaps just change it, but there is at least some question in my mind about the appropriate change. Being short on time, I'm not going to bother to think about it further. Authors need to think about such issues instead of just assuming that the editor will fix them all up. Is this intending to grant some permission to the processor? Or is this just commenting on a possible state of affairs? It seems to me that the subject matter is outside of the scope of anything that the Fortran standard requires and that therefore its is superfluous to talk about giving it permission to do things in some way. But perhaps someone thinks differently. Issue 159 - C function terminology The paper's J3 note on this in 12.5.3 is numbered 159. I also appended "See also 2.5.10." Issue 160 - But not both The "but not both" in 12.5.3 seems problematic in the case where the Fortran processor is its own companion processor. Issue 161 - actual args and C formals The paper's J3 note on this in 12.5.3 is numbered 161 Issue 162 - procedures vs subprograms vs entry Is it procedures or subprograms that have binding labels? Section 12.5.2.7 talks about (and is titled) binding labels for procedures. Section 12.5.3 seems to randomly switch between talking about binding labels of procedures and subprograms. I think this is confused. In any case, I am. Along simillar lines, note that a procedure whose name is specified by an ENTRY statement is still said to be defined by a subprogram. It isn't actually defined by the ENTRY statement. The entry statement just defines the name (and entry point), not the whole procedure. See 12.5.2.0 and 12.5.2.4. I don't think you'll find either of them saying anything about a procedure defined by an ENTRY statement. This incionsistent wording was used several places in 99-118r1; I've not bothered to track them al down. . Issue 163 - binding labels as global "entities" The paper's J3 note on this in 12.5.3 is numbered 163. I added the following para to the J3 note: I'll also add that the current wording prohibits a binding label from being the same as the name of the procedure that has the label. We certainly don't want to prohibit that; indeed its the "normal" case. Finally, if we are going to say that binding labels are global entities, then they ought to first be entities (see glossary entry for "entity"); that one is pretty trivial to fix since we do use the term "entity" for a wide variety of thingos, it won't hurt to add one more to the list. Issue 164 - refs for linkage and prototype The paper's J3 note on this in 16.0 is numbered 164. I added the following para to the J3 note: I also wonder whether we shouldn't be using the term "associated" in some of these contexts. It seems to me that, at least for variables, this "linked" business sounds an awful lot like what Fortran normally calls "associated". Perhaps C uses the term "linked" and thus we need to also mention it. But if native Fortran terminology (associated) is pertinent, then I Issue 165 - definition of interoperate The definition of "interoperate" in 16.2 doesn't tell me anything. It is pretty much self referential. It says that something interoperates if it is described as interoperating in this section, but it still doesn't say a thing about what this *MEANS*. In a definition of a term like "interoperate", I don't care about all the rules for what interoperates with what; that comes later. I want to know what it means to say that 2 things interoperate. There is probably a reason why we didn't say that a Fortran namelist interoperates with a C struct (and its probably a pretty good reason); you'd never guess why we didn't from the definition here. "Some correspondence exists" doesn't hack it, particularly when it just then says that the correspondence is defined by this section. I might paraphrase the definition given here as "a Fortran entity interoperates with a C entity if we say it does.". We could simplify a lot of the definitions in section 2 if we replaced them all by statements like "a Fortran entity is an XXX if it is defined to be one by this standard". And what kinds of entities does the term apply to. I'm not clear on this point. I think you are mostly talking data entities and procedures, but I find it a bit confusing. At times it almost seems like we are talking about types as being interoperable; at other times it is more like data entities of those types. I think we mostly mean data entities; but at times it seems confused. For example, 16.2.1 starts off talking about the correspondence between Fortran and C types. Its not until the 3rd sentence that it mentions entities of such types. And then in the 4th sentence we specifically talk about types as beinginteroperable. This jumping back and forth between types and entities of the types is confusing. Another matter of terminology that is inconsistent is whether we say that something "can" interoperate or "does" interoperate. We often talk about whether a Fortran entity can interoperate with a C entity. From this phrasing, I would expect that its interoperability is just established as a possibility. For example, one might think that a Fortran entity can interoperate with a C entity as long as the Fortran entity is of a plausible type, but it only *DOES* interoperate with a C entity if it is actually linked (or associated or whatever we call it) with some C entity. I'm not sure whether that was the idea or not. It mostly just looks to me like we randomly switch between saying that something can or does interoperate without meaning anything different. If we mean one thing, we should use one term. If we mean two things, then we need to be much more upfront about defining what they mean. We don't seem to have a definition of even one meaning yet, much less two of them. Issue 166 - type parameter prohibited from interoperating? I've inserted the phrase ", that is not expressly prohibited from interoperating with any C entity," exactly as specified by 99-118r1. I'll let someone else fix the fact that its placement in the sentence makes it completely confusing (or am I wrong in assuming that you probably wanted it to modify "entity" instead of "type parameter"?). I'll get on with typing instead of rewriting. Issue 167 - C_PTR The bit in 16.2.2 about "that is not expressly prohibitted" seems a bit vague and potentially circular. What do you really mean here? Do you just mean that it can't be a pointer or allocatable? If so, much simpler to say that. I see circularity in that 16.2 says that anything that is not allowed is prohibited. I also note that we usually use the term "explicitly" instead of "expressly". Nothing really wrong with the word "expressly", except that its not the one we've mostly used. (I see only one exception - in section 2 on free form source). Same problem in the first sentence of 16.2.3 on structs, which has the additional problem that the phrase appears to modify "type" instead of entity. Issue 168 - Annex C on non-fortran procs The paper's J3 note on this in C.9.2 is numbered 168. paper 99-113r2, c_loc Issue 169 - C_LOC I'm not 100% sure whether the "J3 discussion note" was intended as a J3 note to go in the paper or not. I added it in numbered 169, along with the following extra para. I'm not yet clear on whether it is types or objects that interoperate, but I'm sure that objects do not interoperate with types. Issue 170 - Sample code for C_LOC If I read correctly, we require explicit interfaces for all C procedures. It would therefore seem appropriate to have the sample code for C_LOC in 16.2.3 follow the requirements of the standard rather than trying to substitute a comment. paper 99-117r2, interop glossary Issue 171 - interop glossary I was very tempted to just bounce the whole paper 99-117r2 for not paying sufficient attention to the format of the glossary and to other material already in the standard to be suitable as edits, but I went ahead and took care of most of the trivia. However, one of the failings involves a technical issue that I refuse to take the time to check. Instead, you just got my off-the-top-of-my-head guess. The paper capitalized every glossary entry, which is not the style we are using. I downcased most of the entries, but realize that case matters in C, so some entries should be capitalized where it actuially makes a difference. I guessed that it was appropriate to capitalize _Complex, INF, NaN, and IEEE exceptions (I'm sure about the last one). I guessed that it was not appropriate to capitalize the others. Hmm, doesn't look like we use INF in all caps in c15. Oh heck. Let someone else make this consistent. Issue 172 - companion processor definition The glossary definition of "companion processor" does not agree with the definition in normative text. This seems unfortunate. For example the glossary entry says that it is by a means other then Fortran, whereas the normative text says that it might be a means other than Fortran or it might be the Fortran processor. Issue 173 - IEEE flags definition Loosely speaking, I'd say that the term "loosely speaking" is inappropriate for a glossary entry, even though it is non-normative. And just deleting the term isn't going to help the additional problem that it is accurate. What is a "sticky flag"? The "set as a consequence of every" bit almost sounds like it just flags whether a floatting point computation has occurred. What is a mode of operation? What does it mean to raise an exception? Oh, and I almost missed - what is this automatic transfer of control business? Sounds like the old block-structured proposal that we don't have. I don't like it when glossary entries raise more questions than they answer. Oh yes, and definitions really should be in the singular. This one had so many bigger problems that it didn't seem worth my trouble to try to fix that one. Um, say. On further thought, I seem to be missing something here. A quick scan does not reveal the term "IEEE exception" used anywhere in the standard. Why do we have a glossary entry for a term that isn't used? There is a module named IEEE_EXCEPTIONS, but that's clearly not what this entry is defining. And there is, of course, lots of discussion of exceptions in c15, but I can't find the term "IEEE exceptions." Issue 174 - Glossary entries for C types Although I am one that pointed out the need for definitions of the C terms that we reference, and I suggested glossary entries as possibilities, now that I look at the result, I'm not sure that it was a good suggestion. Sorry for the reversal, but realize that lots of these unresolved isssues are thrown together pretty quickly and their proposed approaches aren't necessarily fully thought out. The first thing that struck me was that the previous glossary entries were all for terms used in the English text, not for language keywords. Although there is occasionally a language keyword with the same spelling, it is the English word that is the glossary entry. Most of these C things, however, are strictly language keywords. It looks anomalous that we have glossary entries for the C data types _Complex, double, float, and int, yet we do not have glossary entries for the Fortran equivalents of COMPLEX, REAL, DOUBLE PRECISION, or INTEGER. Cases like "struct" strike me as more reasonable. We do use the phrase "C struct type" in text as a descriptive term, rather than solely as a keyword. It seems comparable to "derived type", which we do have a glossary entry for. I was also struck by how singularly uninformative the entries for the C terms were. We couldn't even be specific enough to mention that these things are data types. They are just "technical terms." We could have said that about almost every entry in the glossary; I don't find it useful. If its not useful, then we don't need it in the glossary. Then there is the fact that the glossary is non-normative. We still have nothing normative that says what those things in the last column of table 16.1 are. We use the term "C types" in reference to them, but that isn't really sufficient. It appears to me that this section is at least the main place where we reference the C types, so it should explicitly say what they are. I'd say that somewhere in this section is the place to put a normative statement about these being defined in x.y.z of the C standard. The glossary, being non-normative, is a place to collect definitions in a convenient form. It is, however, just supposed to be a convenience; the standard has to be completely well-defined without the glossary. Issue 175 - Glossary entry for NaN The glossary entry for "NaN" uses the term "domain-specific information." I find its use in this context inadequately defined. I suppose it refers to an application domain, but it certainly also brings to mind the domain of a function. It's probably better to just avoid using the term rather than needing to define it for just the one use. While on the subject, the grammar of the sentence should get fixed, since I doubt that the result of 0.0/0.0 is intended to be an example of domain-specific information. (If it is, then I'm really confused). Issue 176 - Glossary entry for rounding modes "Rounding modes" (plural) is "a facility" (singular)? I don't think so. But I'm also dubious that a rounding mode (singular) is reasonably described as a facility either. So I'll let someone else fix it. Note that definitions should usually be in the singular. Issue 177 - Glossary entry for linked Numbered the J3 note from the paper as 177. Also added the following para. Agree. This wording makes me think that you actually have written both a Fortran and a C version and that they are connected. Its words might be technically correct, but I find them confusing. Suspect I'm not alone. paper 99-108r1, initial/final Issue 178 - parent component subobject The J3 note in the paper on this is numbered 178. Issue 179 - Override initialization I can't follow this. It seems organizationally confused. Is this actually trying to tell me what happens in each of the 3 cases listed, or is it just introductory material trying to say that these are three things that will be influences in ways to be described below. My first inclination was that you were going to tell me what happens in each of the 3 cases. That's what I'd normally expect when seeing something like this. But it seemed woefully incomplete. Most notably item (1) (which doesn't even say that nothing happens - its just empty), but the other cases also left me feeling like thay hadn't really said what happens. If its just to say that these three cases will be different in ways described below, then it should *JUST* say that. Instead, it looks like it tries to say that, plus mix in a little bit (but not all) of material about each case. I find this a very confusing presentation style. Issue 180 - Is initialization a process or a syntax? We seem to be simultaneously talking about initialization as a process and as a piece of syntax. It probably happens throughout this section, but it first really hit me in the above para, where we say that "initialization consists of a single defined structure constructor", while we have been talking about the process of initialization. The first sentence of 6.3 says "Initialization is the process...". I don't think a structure constructor is a process. Issue 181 - elements allocated through a pointer I don't understand note 6.17 in 6.3.1.2.2. Admit I didn't spend very long trying to puzzle it out. My first confusion was the word "elements". I'm not sure what kind of elements these are. Array elements are the only elements that occur to me off-hand, but I'm mostly just lost here. Perhaps if I could figure out what elements of what we were talking about, the rest might be more clear. We could then go on to explain the "allocated through a pointer" part. Am I allocating through a pointer when I allocate a%b%c%d where a%b is a pointer? Um, say. I see there is more of this "element" stuff later. Are we trying to introduce a synonym for component without actually saying so? Or do we really mean array element (and if so, is a scalar considered to be an element of itself)? Or is it something more subtle? Issue 182 - Effect of initialization Why the "effect" of initialization? Seems to me that we are talking about different initializations happening, not just the initialization having different effects. Simillar comment about finalization later. Issue 183 - Provide for finalization I'm sure glad there is a note explaining this (6.3.2.1(1). I'd be happier if I thought that the normative text supported what the note said. I know of no normative definition of "provide for" and I sure can't deduce that it means what the note says. And as I read it (admitedly very poorly), this says that we can't use structure constructors for any type that has a final procedure, because the structure constructor creates an anonymous object that we have no way of "providing for the finalization of". Simillar problems with other anonymous objects. Maybe I just misread it. Or maybe it doesn't really say, but rather assumes that it will just be interpreted to mean "do the right thing." And I'm left in the air when this goes out of its way to note that there might be multiple final procedures and then just tells me that an unspecified one of them will be invoked. I suppose there must be more on this somewhere. Can we at least have a hint or an xref? I'm also quite surprised to see that we feel it necessary to say that this requirement applies only to standard-conforming programs. I guess I thought that's what the whole document was about. Does the standard have any requirements that apply to non-standard-conforming programs? Issue 184 - parent component subobject The J3 note in the paper on this is numbered 184. Issue 185 - Further than what? Further than what? Is it simply that finalization of the linkage involves no operations, or is it really that it involves no further operations in addition to some other ones that I haven't figured out? And why did we switch from talking about finalization of the linkage to finalization of the object? Issue 186 - Accessed in order to be invoked Do the words "accessed in order to be" add anything here? As best as I can tell, they add nothing but complication. Issue 187 - First declaration What does "first declaration" mean? There is an ancient Dick Weaver interp request (number 96) that we never did manage to resolve, which asks for a definition of the term "declaration." Since we are a bit hazy about what declaration means, I'm even less sure about what the first one is. I tended to feel that part of the problem was that Fortran doesn't actually have a well-defined concept of declaration. There are just a whole bunch of things that can contribute information. And after you see the whole scoping unit, you guess what you have from the information you have collected. (As in: hmm...isn't given a dimension attribute, but is used with a parens after it - must be a function). Sort of a mess, but that's the hand we were dealt. My general ill-defined notion of declaration in Fortran was that the declaration of an object was "something like" the collection of all its attributes, including those specified implicitly and explicitly. I didn't think you could have multiple declarations of an object. Instead I thought you might have multiple specifications that contributed to a single declaration. Guess that just shows my ignorance? (Quite possibly true). Assuming that each of the statements that specifies an attribute of the object is a declaration of the object (I guess the intent must be something like that), is an implicit statement a declaration of all implicitly typed objects (my guess is "no"? Is the dummy argument list a declaration of the dummy arguments (my guess is "yes")? Is the first appearance of an implicitly typed variable its declaration (my guess is "yes"). This needs major work if you want to use that terminology. My recommendation is to punt and say something much easier to make concrete. Issue 188 - "balances" It bothers me when we feel the need to use quote marks around English words in normative text. The quote marks mean that the word is not being used with its actual meaning. Perhaps we should say what we mean instead of making the reader guess - particularly in the normative text. Issue 189 - change from TR The note in the paper on this subject is numbered 189. Issue 190 - Initial/final I have not had time to do a careful job on the edits from paper 99-108r2. I have just imported large parts of it (most of section 6.3) as is, without taking much time to actually think about it. I have't even really reviewed the wording and editorial issues, much less the technical details. I'm playing typist here. (At least the rtf format imported into Frame pretty easily, making that part go relatively quickly). There is too much that is too new and too late for me to have the time. This J3 note is more to flag the section as being not as well reviewed as most than to point out specific issues. I'll just mention a few quick things that occur to me without study. (Later...I did end up doing several other J3 notes, but they still don't reflect my usual level of care). I'm not entirely pleased with the term "finalization". Yes, the paper mentions it as a placeholder. No, I don't have a great alternative to present. "Destruction" (along with "destructor") has some attraction, even though we don't currently use the term "constructor" (because of conflicts with other terminology). I would consider the possibility of using a different term for our existing array and derived type constructors so that we could use that term here. I count only about 80 lines where the term is used, 65 of them in c4 and c7. Verifying each for a global change does not look like an overwhelming task...if someone comes up with a good candidate wording. Or we could just keep "initialization" and pair it with "destruction." To me, finalization sounds too much like making it finally ready for use instead of no longer useable. At work if I finalize a plan or a report or a program, that doesn't mean that I throw it away; it means that it is now complete and ready for use. (It also means that I've given in to a word popular with bureaucrats, but described by Strunk and White as "A pompous, ambiguous verb"). I'm concerned that this will be confusing. I have no great problems with "initialization." Later... I notice that 6.3.3.1 talks about creation and destruction of scoping units. I could see using creation/destruction or initialization/destruction of objects. On another matter of terminology, we appear to have introduced two different meanings of the term "linkage" in simultaneous papers. One in C interop, and one here. I don't think this wise. One of them had better change. I'm not at all sure that the business about content vs linkage is really helping in this section. I might suggest just integrating them in as extra steps in initialization. And there can be words about when some of the steps are skipped (like when pointers are disassociated, etc). As I briefly mentioned in discussion, I consider it excessive to have 6 levels of numbered headings. I had to make a whole new paragraph type in Frame for this because there is not a single other place in the document where there are that many levels. Indeed, I tend to be somewhat dubious of many of the places where there are 5 levels, considering it a sign that perhaps the organization is questionable in such areas. Speaking of headings, I'm a bit leary of the headings beginning with "How". I don't think "how" is really an appropriate term here. That sounds like we are talking about implementation details or something. In a quick scan, I can't find any other headings in the document that begin with "how". We certainly don't have "How DO loops are executed", etc. I'm concerned that it may not always be completely clear when requirement are being made on programs versus processors. Most (but not all) of this section seems to be describing requirements that processors shall follow. Section 1.6 says that we explicitly say when we are specifying requirements of processors. We should do so. I'd generally say that the whole section has an identifiably different style from much of the rest of the standard. Its a little hard to say exactly why. It is also hard to say whether this is necessarily a bad thing. (We may be working on one of the great classics of programming languages, but the standard has a long ways to go to be considered a classic of literature). Several of the sentences pain me in their length, complexity, and resulting confusions about what modifies what, but that kind of thing takes too much time for me to fix. Issue 191 - fixed type I cannot find the term "fixed type" defined anywhere. The only other place I can find the term is 2 uses in comments in C.9.6. Perhaps those should get addressed also. And if we define such a term, I doubt that its definition will be consistent with requiring that initial procedures be bound only to fixed types (which is what the current words say). I suspect that the requirement is on the type of the dummy argument rather than something about the type to which the procedure is bound. Same probelm in final procedures. Issue 192 - pseudo-elemental The pseudo-elemental stuff in initial/final procedures triggers from me a knee-jerk reaction that my worst fears about initial/final are comming true. I was arguing that this paper was too late for edits for a feature like this. But since it is later than such edits should be, I guess it must be quite appropriate timing for substantial issues of specification? The initial/final procedures were "supposed" to be trivial variants of type-bound procedures. Once type-bound procedures passed, the only thing left to make initial/final work was to say that the "names" (INITIAL) and (FINAL) were used to indicate the initial and final procedures. I very distinctly recall that being cited as a good reason why initial/final could be procrastinated - no work of substance - just decide on whether people liked the names initial and final. Instead, we have a major section 6.3, including proposal notes pointing out that it "includes technical material not in the specification and syntax (filling in holes)". I see no such proposal note in the material on "pseudo-elemental", which didn't sound familliar, so I went back to find wherefrom it came. Not a hint about it in 98-138 (syntax), 98-229 (draft edits), or 99-230 (additional specs and syntax). In 97-256 (specs), we have what is obviously a carefully considered position, namely "It is unclear how this syntax would extend to arrays. (Pseudo-elementally?)" So rather than being "just an application of type-bound procedures", we find that initial/final are generic, even though we gave up on generic type-bound procedures as having too many complications (with details that I didn't follow). They don't follow any of the rules relating to overriding of type-bound procedures. They can't be bound to NULL(). And we have introduced a whole new concept of "pseudo-elemental." Did anyone that voted on this paper actually notice and assent to this new concept or did everyone just vote "yes" without reading it. Seems like a pretty big thing to slip in that late. Oh well. If its going to be in, I have (at least) 2 questions right off the top of my head. 1. Are we prepared to explain why these pseudo-elemental things can only be used with initial/final. I have a vision of a horde of users saying that they want something just like that somewhere else, and that yes, they are willing for it to serialize, but they just want to be able to write it looking like an elemental operation, but without the strict requirements that 12.7 places on elsmental procedures. We do have an answer prepared for this obvious request, don't we? Or is this a foot in the door to adding this pseudo-elemental stuff as a general feature applicable outside of initial/final? 2. I couldn't off-hand figure out whether it was allowed to use an actual elemental procedure, or whether it really had to be pseudo-elemental. The words in 4.5.1.5.1 about "if it is not elemental" pretty explicitly rule out actual elemental procedures. If this really means that we can do something that looks elemental, but only if we use a procedure that is not elemental, then I stare in amazement and confusion - just like a lot of users are going to. If elementals slip in as allowed through other rules, then perhaps this could be expressed more clearly. Issue 193 - intrinsic structure constructor Section 4.5.6 leaves me confused about what has happened to the implicitly defined structure constructor. First, its not entirely explicit that the implicitly defined one is the intrinsic one; we just switched terminology from implicitly defined to intrinsic without any clear link. Second, if I am reading this correctly, then defining an initial procedure makes the implicitly defined constructor suddenly become available, even if the initial procedure has arguments completely different from the implicitly defined constructor. This bothers me, and I think its going to be hard to explain to users. They had a perfectly fine, implictly defined structure constructor. But once they add an alternate form, they have to go back and explicitly write code to implement the same thing as the implicit one if they want it stll available? Is this an intentional design "feature?" Along the same lines, I hadn't before noticed that, as soon as we define any initial procedure for any purpose, then suddenly the syntax of initialization in a type declaration statement changes. It is no longer an initialization expression, or indeed allowed to be an expression at all; instead it has to be a single constructor. I know of no other context where we are so specific as to say that an expression may consist of only a single primary. Yes, there are otherwise valid forms that this rules out. For example, this says that you couldn't use an array constructor to initialize an array of the derived type. And it also says that you couldn't put parens around a structure constructor used for initialization (a bit pointless, but otherwise legal). Historically, the initialization expression in a type declaration statement is an expression; like other expressions, its interpretation does not depend on context. We added one special case of context-dependence for NULL(), but that one is at least pretty simple. You are now talking about context-dependence for a user-defined generic. I seriously doubt that all the implications have been thought out. I see that someone noticed one case of ambiguity and patched it with the condition about using the minimum rank in cases where more than one rank might be valid. Want to bet that was the only problem area? I notice that several places talk about the "components" of a structure constructor. See, for example, the definitions of constant and initialization expressions. (That is *NOT* a complete list - its just somewhere I looked at, anticipating problems). That terminology now seems inappropriate. I see that paper 99-108r1 has no edits anywhere in the area of the definition of constant and initialization expressions. Since those definitions don't specify intrinsic constructors, I conclude that a defined structure constructor can be used in a conatant or initialization expression as long as its "components" (interpret as arguments?) are constant or initialization expressions. Since defined structure constructors need not be PURE procedures, it occurs to me that this might open the door to "interesting" possibilities. Hmm. Noting that defined constructors aren't necessarily PURE makes me wonder why they are implemented with subroutines instead of functions. A function would seem more natural and would avoid the special treatment of the first argument. Perhaps it was because we don't have generic resolution on function returns, and it was desired to use generic resolution to select the rank here? I guess that must be it. Is that good enough reason for what otherwise looks more natural? Couldn't we just describe how the rank is selected? We end up having to do some of that anyway because the generic rules don't cover it all (the above stuff about selecting the minimum rank). P.S. Could we come up with a bnf term a little shorter than intrinsic-structure-constructor? Its the longest bnf term in the entire document - or anyway I don't recall any others that didn't fit in the space alloted. Issue 194 - "value" Why the quotes around "value" in 4.5.6.2? If this is meant literally, the quotes are wrong. If this is not meant literally, then it is inappropriate for normative specification. Normative specification should say literally and exactly what it means and shouldn't need quotes. Issue 195 - executable scoping unit In 5.1.2.5, I don't recall the term "executable scoping unit" being defined. And this also leaves me wondering about those scoping units that are not executable. What about the scoping unit of a module? Whatever "executable scoping unit" means, I'd be surprised if it includes modules. If it does, then you *REALLY* need to say so, because it isn't obvious from the term. I guess derived type definitions and interface bodies don't define any objects, so we might be ok there. Issue 196 - Allocation status Paper 99-108r1 deleted about 2/3 of the normative text in 6.4.1.2 (allocation status), with the comment that "This should be covered in 6.3." I did the requested deletion, but I'm more interested in whether the material *IS* all covered in 6.3 than in whether it should be. I'm not sure, but it was a pretty big deletion, so I want to flag it si that we might have some hope of finding where the material went if it isn't all covered. I'm particularly unsure whether 6.3 describes how dummy allocatable arguments or components inherit the allocation status of the actual (except for INTENT(OUT) dummies). And I don't off-hand see, even in the old text, where we explain that the allocation status of the dummy gets copied back to the actual on return. Perhaps that's somewhere else (like chapter 12). So its possible that this is all ok, but I wanted to flag it for verification, particularly considering how non-commital the paper was on the question. If the authors of the paper didn't check whether it was actually covered (as opposed to should be), then someone else should so check. Same concern about the deletion of most of 6.4.3.1 (deallocation of allocatable variables). Someone should check this. Likewise in 6.4.3.2, though the material deleted there wasn't as extensive and looks to me more likely to be ok. Issue 197 - an effect is affected? For something that is in a note to help explain thing, the second sentence of note 6.28 in 6.4.1.2 is awfully hard to read. Its hard to follow what "on an allocatable object" is supposed to modify; presumably neither "procedure", "execution", nor "terminating", but all the way back to "effect". And it seems a bit much that the effect is affected by something. All in all, this sentence reads more like the kind of standardese that we sometimes use notes to explain, rather than like an explanation that makes it all clear. Issue 198 - "Can make it processor dependent" Note 6.32 in 6.4.3.1 says that "Processor merging...can make it processor dependent...". What does this mean? Is it or is it not processor dependent? If the "processor merging" can make it processor dependent, then I think you just said it is processor dependent whether or not something is processor dependent, which makes no sense. If we are trying to say that some cases are processor dependent, but others aren't, then perhaps it would be best to say so explicitly. Issue 199 - Variables have access? The last sentence of the second para of note 5.14 in 5.1.2.3 about INTENT(OUT) refers to a variable having access. I was unaware that variables had access to anything. I thought it was scoping units that had access. Identical words also in note 12.22 in 12.4.1.2. Issue 200 - final procedures in initialization? Two questiona about note 12.41 in 12.6. First, how is it that final procedures get invoked as part of initialization? I would have expected them to be invoked as part of finalization. From this wording, I conclude that it would be fine for them to be impure as long as they are invoked only as part of finalization. Second, why is it that we find it necessary to use normative text to mention the inclusion of procedures referenced via defined operations or defined assignments, while a note is ok to mention the inclusion of initial or final procedures. Seems to me that either both inclusions need to be normative or both could be mentioned in the note. I don't understand why they are different in this regard. Issue 201 - xref to deleted material The last para of 14.6.1.3 had an xref to what was formerly item (3) of 14.7.6. That item was deleted. This xref needs to be fixed.