J3/98-205 Date: 2 Oct 1998 To: J3 From: R. Maine Subject: Additions to list of unresolved issues. The following are new unresolved issues that I encountered in the process of entering the edits to make 98-007r3. All of these are also in J3 notes in the draft. They will be added to the next release of the 011 document. (Yes its a pretty long list. Sorry, but I ran out of time to address all of these myself). Paper 98-189r2, derived type i/o enhancements 23. I note that much of the material on derived type I/O in section 9.4.4.4.3 fails to follow the rule in section 1.6 that "Except where stated otherwise, such requirements and prohibitions apply to programs rather than processors." This section has several requirements that are meant to apply to processors, but do not explicitly say so. Notably, it is the processor rather than the program that is required to pass all the appropriate arguments to the DT I/O subroutines. J3 note added in 9.4.4.4.3 before the first case I noticed. Paper 98-190r2, i/o rounding 24. The ROUND= specifier seems to have unfortunate interactions with G output of reals. Has anyone looked at this? Looks to me like, for example, output of a value 9.99 with a Gx.2 format and round down is going to give "9.0". I suppose that's ok, but it seems like you'd want it to give "9.9". I think the description of G was written with round-to-nearest in mind. I think it may be ok, but I'm not so sure its really what we want. Added J3 note 24 in 10.5.4.1.2. 25. Re the note about the ROUND= specifier in INQUIRE. How about the other way around. If PROCESSOR_DEFINED corersponds to one of the other modes, is the processor required to remember that you specified it as PROCESSOR_DEFINED? That is may the inquire return NEAREST when the OPEN statement specified nothing or even explicitly specified PROCESSOR_DEFINED. The answer isn’t obvious to me. Added J3 note 25 in 9.7.1.25 26. We need to add IEEE support_IO to the lists and sections at the start of chapter 15. J3 note 26 in 15.9.27 per paper 98-190r2. 27. We need to revisit the rule that the argument "shall be of type real and such that IEEE_SUPPORT_DATATYPE(X) has the value true" since this makes it impossible to write a portable program that uses this function on a machine that doesn’t support IEEE for some real types. J3 note 27 in 15.9.27 per paper 98-190r2. 28. Should we specify the DECIMAL= and ROUND= modes here for internal files? J3 note 28 in 9.2.2.1 per paper 98-199r1. 29. The description of BLANK= in the OPEN statement is incorrect, as it fails to account for possible BN and BZ edit descriptors. It would better be described in a manner simillar to DECIMAL= as just providing the initial form. It is possible that other OPEN statement specifiers have simillar problems; I didn't check them all. Added J3 note 29 in 9.3.4.6. 30. The note about ROUND= specifier in INQUIRE appears inadequately integrated with derived type I/O. This note refers to what was specified on the OPEN statement, assumimg that this is the same thing as the current state; that may not be the case in a derived type i/o routine. Simillar integration issues in normative text about P, BN, BZ, RU, RD, RN, RZ, S, SP, SS, DC, DP in sections 10.6.x. Several of those sections say that these are whatever was specified on the OPEN statement at the beginning of each I/O statement; not true in dt io routines. Added J3 note 30 in 9.7.1.25 31. I don't really consider it acceptable to have the description of the DC edit descriptor just say that the rest of the standard was lying. If I read the section of the F edit descriptor and it says unambiguously and without exception that a period will be used, then I expect it to be telling the truth. I don't like "duelling sections", where one section says one thing and another section says something contradictory. At the least, I'd say that each affected section should xref the DC edit descriptor section and say that it is so affected. I don't think the number of affected sections should really be too large. Even better would be to actually change the affected sections so that they cover both the DP and DC cases. Looks like there has been at least an attempt to do this for the comma vs semicolon stuff. Lets do it for the decimal point also. And while I'm thinking about it, we might want to check the character names in 3.1.4,, where the "." character is called the "decimal point or period". I'm afraid that my familiarity with the European terminology is a bit weak. I recall that the comma is sometimes used where we use the period, but I forget what they call it in such contexts. Is it still perhaps called the "decimal point"? If so, perhaps we should stick to using the term "period" for the "." character, and use the term "decimal point" for whichever character serves that role. But there must be a standard terminology for this, so I better not invent my own. Added J3 note 31 in 10.8 paper 98-199r1, volatile 32. ISO10646 refers to the 32 bit character set. Added J3 note 32 in 13.15.96 per paper 98-199r1. 33. Do we want to add a blank (possibly optional?) or some other punctuation between the ISO and the 10646 in the name? Having a letter "O" imediately followed by digits is very error prone. The first 2 digits being 1 and 0 make it even worse. For that matter, I guess the "I" is also problematic. Might we get people reading this as 15010646? Added J3 note 33 in 13.15.96. 34. The copyright issues of adding the example from MPI-2 need to be resolved before releasing the final standard with it in section C.2.3. Also, if this stays, wee need to add a reference in section 1.9. Added J3 note 34 in C.2.3 per paper 98-191r1 (with slight rewording and addition). paper 98-186r1, partial type bound procedure edits. 35. The syntax of the "contains" part of derived-type-def in R422 is done in a manner inconsistent with the style of all the other syntax. In every other case where there is a statement that is part of a construct, we give the statement a name ending in -stmt and have a separate syntax rule showing what that statement looks like. In R422 we just have the lines CONTAINS and PRIVATE directly in the syntax of the construct, without separately labeling them as statements. This is particularly confusing because there *ARE* such things as contains-stmt deined in the standard. The way I read it, this thing is not actually a contains statement, even though it looks identical to one. It isn't any kind of statement at all, but is just part of the syntax of the construct. I think thats wrong. Look at pages 9-10 for samples to follow. I could probably do this myself, but my current priority is entering what has been passed instead of rewriting it. 36. There are various problems with the 2 paragraphs about PASS_OBJ in 4.5.1. First, it seems to me that the restrictions here should be constraints. And I suspect that the any of the material that doesn't end up in constraints might go better elsewhere, perhaps in a 4.5.1.x. Note that 4.5.1.0 has no other explanatory material; its just syntax. Second, the restriction talks about requirements on proc-interface, but fails to require that proc-interface be specified. This certainly needs to be clarified as to whether this implicitly means you have to specify proc-interface, or whether the restrictions only apply to any proc-interface that you do specify. This question is even more to the point for the second of these identical paragraphs, which seems to place restrictions on proc-interface in a context where I don't even see a place for such in the syntax. Perhaps the restriction needs to be in terms of the interface and its explicitness instead of the syntax used to express it. Added J3 note in 4.5.1. 37. Several of the constraints on data-component-def-stmt should either have simillar ones for proc-component-def-stmt or they should be placed and phrased in a manner that makes it clear that they apply to both cases. The 2 cases I noticed are the first and fourth constraints (no duplication and pointer types declared before use). Simillar coments for binding-attr. Added J3 note in 4.5.1. 38. (Van says) I don't see how select kind can be differently useful from type-bound generic procedures if scalar-initialization-expr is allowed to be more general than kind-parameter-name. Added J3 note in 4.5.1 per paper 98-186r1. 39. We need to do something to make explicit that case-stmt can be either executable or non-executable depending on what kind of construct it is in. Posssibly something in 2.3.1. I don’t think its good enough to just say it is the same statement in select case and select kind without any distinction at all. Yes, the syntax is the same, but the executable vs non-executable distinction needs to be made. Added J3 note in 4.5.1. 40. The words in 4.5.1.5 about the accessibility of type-bound procedures need work that I didn't bother to do. I'm suspicious that the best thing to do is to eliminate those words from this section and instead make sure that the section on accessibility adequately covers type-bound procedures. Several problems. 1. Every type is accessible, so the "if" condition is moot. At issue is "where" the type is accessible, not whether it is accessible somewhere. 2. Accessing a type never makes anything accessible. The accessibility is required in order to access the type - it isn't a consequence of accessing it. 3. It seems anomalous that we explcitly talk about public, but fail to mention anything at all about private. The private bindings are also accessible some places (namely in the defining module). But the section on accessibility says most of this already. I'm suspicious that we would be better off to just make sure that it covered anything else needed. I think that is better organizationally. Added J3 note in the new 4.5.1.5. 41. The usage of NULL() in procedure type-binding in 4.5.1 and 4.5.1.5 does not appear to be covered in 7.1.4.1, which discusses the interpretation of NULL() with no arguments. Come to think of it, the problems are deeper than this. It is going to take some pretty major surgery to explain how the NULL intrinsic can have an "actual argument" that isn’t an entity at all. I don't even want to think about how many places it might affect to introduce the concept of a type or an interface as an argument. I'll let someone else consider whether we really want to do that. Without at least some work, this flatly contradicts the definition of the NULL intrinsic (which says its actual argument shall be a pointer) and of actual arguments in general. Added J3 note in the new 4.5.1.5. 42. Is it intentional that we allow a pure type-bound procedure to be overriden by a nonpure one? We don't allow the other way around. And we don't allow an elemental to be overriden by a nonelemental. I couldn't tell for sure whether this was intentional or accidental. It might well be fine, but I wanted someone else to verify this. I noticed it was the only requirement for agreement that was asymetric in 4.5.3.2. Added J3 note in 4.5.3.2. 43. I can't come up with any context in which the code shown in notes 4.31 and 4.32 (with functions point_2d_length and point_3d_length) would be legal. So perhaps we shouldn't offer them quite that way as examples. I'll let somebody else fix them. (Hint: exactly how is it that the derived type magically became accessible in these functions?) Added J3 note in 4.5.3.2. 44. I'd say that the paragraph in 4.5.1.6 on accessibility of procedure bindings needs a lot of work (and is probably going to end up as more than an isolated paragraph). I've spent too much time on this, so I'm shirking said work at least for now. First, there are wording problems relating to default. It says that the default is PUBLIC, but then says that the default can be changed. What we have here is a default for the default, but that's too messy to say. Need better wording. We don't give an interpretation for what it means for a binding to be private or public. I presume it should mean something simillar to what such means for components, but we need to actually say this. Probably should review all of section 4.5.1.6. While doing that review, better fix the statement that the component names are all private if a derived type definition contains a PRIVATE statement - since the part after the CONTAINS is still contained in the derived type def. And what does it mean to override the accessibility? Does this have anything to do with overriding inherited bindings? While on the subject of overriding, are there any requirements relating to accessibility changes when overriding a binding? Added J3 note in 4.5.1.6. 45. The 2 sentences about type-bound procedures in 12.4 need work. They just say that the binding is determined by the dynamic type. This is not specific enough. What is the exact algorithm. This doesn't ever say anything about a procedure actually getting invoked. All it talks about is how the binding is determined. Do we just determine a binding and then stop? Added J3 note in 12.4. 46. The term "type-bound procedure" defined in 4.5.1.5 (and then used in elsewhere) is probably not very appropriate. This shows up in awkwardness of some of the wording. The problem that I see is that the type-binding is not a characteristic of the procedure itself. Instead it is related to how the procedure is referenced. The same procedure can be referenced either as a non-type-bound procedure or as one bound to (possibly multiple) types, which the terminology seems to contradict. And if you try to avoid this by saying that it is only the binding-name and not the specific procedure that is type bound, then you have the problem that a type-boud procedure is not a procedure. We have a definition of "procedure" (2.2.3 and glossary) and this doesn’t fit it. I think it would probably be better to talk about a type-bound reference or something more along that line, tying the type-binding to the form of reference instead of to the procedure. Added J3 note in 4.5.1.5. 47. There are two wording problems with the second sentence of 12.4.1.1, which discusses PASS_OBJ for component reference forms. I’m getting too far behind to fix all these kinds of problems. First, its is a bit vague to say "a procedure reference that uses a structure component". In what fashion is it "used"? Second, a part-ref is not an entity. It is just a piece of syntax. I don’t think you can pass a part-ref as an actual argument. Added J3 note in 12.4.1.1. 48. Several problems relating to the paragraph on binding names in 14.1.2.5. First, the allusions to appearing within a call statement or function reference are way too vague. It must appear only in a very specific syntax. Even if one rules out the argument list, you need to distinguish between "call object%sub" and just plain "call sub". Nothing in 14.1.2.5 distinguishes these two forms. Second, this fails to distinguish between the two places where a PRIVATE statement may now appear in a derived type definition. This fix also needs to go in the first paragraph of 14.1.2.5. After having elsewhere said that the accessibility of components and bindings was independent, the same exact words are used in the two applicable paragraphs of 14.1.2.5, making them appear identical. Added J3 note in 14.1.2.5. 49. One that I'm afraid turns into an interpretation question against f90 and f95. I'd think you would want a non-private binding name to be accessible anywhere an object of the type was accessible instead of depending on the independent accessibility of the type. It should be just like a component or a type-param-inquiry in this regard. Alas, the situation for components looks questionable. Interpretation 32 is pretty explicit about stating that components may be accessible even when the type is not. But 14.1.2.5 is equally explicit about saying the opposite. I'd speculate that interp 32 failed to make a needed edit in 14.1.2.5. See the words in 14.1.2.5 about type-param-inquiry for a sample. I may submit an interp on this. Added J3 note in 14.1.2.5. 50. I put in the glossary entry for "binding", but it doesn't jibe very well with the normative text. Is a procedure bound to a name or to a type? I think its probably bound to a type. But in any case, lets not randomly switch the terminology. Also, it is probably best to avoid use of the term "association" in ways not included in its glossary entry. Added J3 note in Annex A. 51. Perhaps I'm just tired, but I can't parse much meaning out of the glossary entry for "passed object dummy argument" unless I already know what it should say; and even then I have to work at it. The first "that" modifies procedure, though that's not entirely clear (leaving me think we are always talking about the first argument of such a procedure). The second "that" modifies binding, which is reasonably clear. The really tricky part is how I'm supposed to know that the third "that" goes back and modifies "argument" from the beginning of the sentence. Perhaps the comma is supposed to clue me in to this (it doesn't). And what are the 2 things connected by the "and". Eliminating the modifiers of "procedure" this reduces to "The first argument of a specific procedure, and that has the same type...". I suppose I ought to be able to fix this, but I've spent too much time on rewriting already. Added J3 note in Annex A. 52. The glossary entry for type-bound procedure uses two terms (procedure and associated) in ways that are inconsistent with their definitions elsewhere in the glossary. This seems a bit much. Added J3 note in Annex A. Paper 98-184r2, select type 53. We have a bit of a mixed metaphor in the terminology for extensible types in 4.5.3 and elsewhere. A type is an "extension type" of its parent instead of a "child type" or some such. Perhaps we should consider making the terminology more consistent, either using geneological metaphors or not, rather than randomly mixing them. We also have the geneological term "inherit", and paper 98-184r2 tried to introduce the term "ancestor", although this may not be necessary for the small use that was made of it. Thus, it looks like we are using the geneoligical metaphor in more places than not. I suggest at least consideration of replacing the term "extension type" by "descendant type". That appears to be the main inconsistency. The terms "extensible type", "extended type", and "base type" seem ok, as does the syntax of the EXTENSIBLE and EXTENDS keywords. Anyway, I don't see any obviously better replacements and they appear enough places that a replacement would need to be obviously better to be worthwhile. But I think "descendant type" or something simillar is noticably more consistent than "extension type" to describe that relationship. It also keeps me from getting confused between "extended type" and "extension type". (I keep having to look it up to see that "extension type" is the one that we always use with "of" because it is about the relationship of two types, while "extended type" is a property of a type, without specifying a relationship). There is nothing actually wrong with the way it is now, but I do suggest that this is a good time to review the terminology for consistency. My review suggests this one change. Added J3 note in 4.5.3. 54. Paper 98-184r2 tries to modify the wording of the syntax rukes and constraints for the CASE construct in 8.1.3.1, apparently to minimize duplication of simillar text for SELECT CASE and SELECT TYPE construct.s. Whereas this seems like a desirable goal, the proposed edits didn't work. They resulted in constraints that referred to the undefined terms "select statement" and "select construct". I didn't try to work out a fix. Instead, I just omitted the edits. I'd rather leave the edits for SELECT TYPE incomplete than to break the formerly ok syntax rules and constraints for CASE. This does leave SELECT TYPE incomplete, and the fix might involve changes to the wording of CASE, but not the changes proposed in 98-184r2. Added J3 note in 8.1.3.1. 55. If executionm of a SELECT TYPE construct causes the expression to be evaluiated, as stated by the first sentence in 8.1.4.2, then this places severe, probably unacceptable constraints on its use. This would require that it be legal to evaluate the expression. In particular, there must be no undefined values or disassociated pointers in the expression. I seriously doubt this is desired. Added J3 note in 8.1.4.2. 56. Multiple things in the second para of 8.1.4.2. I'm too busy to investigate them now. (Although first numerically, this is the last paper I entered for this rev, and I'm out of time). Whatt are the bounds of associate-name? The text mentions extent, but leaves bounds unmentioned. This might also affect the last sentence of 14.1.3. What does the condition "if associate-name is assigned" mean? I know of no such term in the standard. The closest interpretation I could give is that it is assigned if it appears on the left side of an assignment statement. But I suspect this really intends to cover lots more than that. Does this condition apply globally or only within the block actually executed - it doesn't address such issues. Finally, I don't recall that we defined the term "assignable", and if we did, then I don't think an expression could ever qualify. Look at 12.4, to see how a simillar issue is handled for actual arguments; variable is listed as a separate possibility; if you pass a variable, it is not considered to be an expression because expressions are never definable. I could probably fix all this, but not in the time I have. More. Is it allowed for there to be a variable in the procedure scope that has the same name as the associate-name? If so, what are the implications. Added J3 note in 8.1.4.2. 57. I think I recall that the reason for allowing a non-extensible type as the expr in a SELECT TYPE statement was to get the effect of a PASCAL WITH statement. That is a useful functionality, but on looking at the result, I must wonder whether this is aa reasonable spelling of it. It is very verbose for the purpose. For example, the necessity to say either TYPE DEFAULT or TYPE IS (whatever) just looks like pointless extra typing (no pun intended). It is also extremely non-intuitive. *NOBODY* is going to think to look under the SELECT TYPE construct to find this functioanlity. And on reading code that someone else wrote, the meaning will be obscured by the fact that TYPE is completely unrelated to the usage. I’d have to count this as an obscure trick rather than as a natural usage. If we really want this feature, perhaps we should consider just adding it on its own with a more natural spelling instead of providing a hidden trick. Added J3 note in 8.1.4.1. 58. The para of 8.1.4.2 covering TYPE IN. I find the first sentence pretty hard to follow. It also uses the term "nearer ancestor", which isn't defined. And I failed to add the definitions of ancestor and nearer ancestor meaning to rwrite this. If the rewriting isn't done, then at least something like those definitions should be added after all. Also I don't like saying that a name is an object - we normally distinguish names from objects. Finally, the type guard statement has a type-name yet we refer here to the CLASS that it names. The connection might be made more explicit, particularly since I don't even see a restriction that the type names used in TYPE IN be extensible types. Looks like the block of a TYPE IN can never be selected if its type isn't extensible, so it would be silly, but I don't recall that the standard yet includes a constraint against writing silly code. Added J3 note in 8.1.4.2. 59. In the para on TYPE DEFAULT in 8.1.4.2, I was not aware that expressions had declared types. Added J3 note in 8.1.4.2. 60. In 14.1.3, is it appropriate to say that the associate name has the scope of the construct when it has different types in different blocks of the construct? Might it be better to consider it to be a set of variables, each with the scope of one block of the construct? I'm not sure this would be best, but it seems a question worth asking. Added J3 note in 14.1.3.