ISO/IEC JTC1/SC22/WG5 N1629 Result of the interpretations ballot 2, N1622 Key for the Result line: Y Vote passes unconditionally. C Vote passes, subject to J3 considering the comments and reasons and making no change that alters the technical content. N Vote fails. Returned to J3 for further work. F03/ F03/ F03/ F03/ F03/ F03/ F03/ F03/ F03/ F03/ F03/ F03/ F03/ F03/ 0030 0031 0032 0033 0034 0035 0036 0037 0038 0039 0040 0041 0043 0044 Cohen N Y Y Y N Y Y Y Y N Y Y Y Y James Y Y Y Y Y Y Y Y Y Y Y Y Y Y Long Y Y Y Y Y Y Y Y Y Y Y Y Y Y Muxworthy Y Y Y Y Y Y Y Y Y Y Y Y Y Y North Y Y Y Y Y Y Y Y Y Y Y Y Y Y Reid Y Y Y Y Y Y Y Y Y Y Y Y Y Y Whitlock Y Y Y Y Y Y Y Y Y Y Y Y Y Y Result N Y Y Y N Y Y Y Y N Y Y Y Y F03/ F03/ F03/ F03/ F03/ F03/ F03/ 0045 0046 0047 0052 0053 0054 0055 Cohen N N N Y N Y Y James Y Y Y Y Y Y Y Long Y Y Y Y Y Y Y Muxworthy Y Y C Y Y Y Y North Y Y Y Y Y Y Y Reid Y Y C Y Y Y Y Whitlock Y Y Y Y Y Y Y Result N N N Y N Y Y Comments and reasons for NO votes .................................................................................. .................................................................................. Malcolm Cohen NO vote of F03/0030. The edit for [365:13-15] makes the text read "the result for an intrinsic real operation or assignment with finite operands ..." this has two flaws (1) it is now ambiguous (2) assignment doesn't have "operands" there is a pre-existing flaw, in that (3) assignment doesn't have a "result" This needs significant editorial fixup. ---------------------------------------------------------------------- NO vote on F03/0034. The edit [376:15]. Subclause 14.10.12, Result Value, line 2. After "Note:" add "if X is normal,". changes a correct and informative note into a misleading note. The added condition removes subnormal numbers from consideration (zero, inf and NaN are already removed); however the stated conclusion is true for subnormal numbers (that IEEE_LOGB(X) is equal to EXPONENT(x)-1). That this conclusion is true is the subject of F03/0054. ---------------------------------------------------------------------- NO vote on F03/0039. The edit [389:16+]. Subclause 14.11, Note 14.17, at the end of the final paragraph, add "This HYPOT function does not handle infinite arguments in the same way that the hypot function in the C International Standard does." is irrelevant and misleading. It is irrelevant because (a) this is not the clause on C interoperability (b) even if it were in the C interoperability clause, whether an example of user code has the same behaviour as a library (or intrinsic) function defined by another standard has nothing to do with this standard. It is misleading because it implies that other functions, whether intrinsic (actually defined by the standard) or example user code might necessarily have the same behaviour as that of another function defined in another standard. This is most emphatically NOT the case! For example, our FLOOR and CEILING intrinsics return different data types from the C library functions of the same name. Similarly, for the user-written FUNCTION SIN in clause 16 (which has its body omitted) there is no implication that it has the same behaviour as "sin" in the C standard - or in fact "sin" in the Fortran standard itself! ---------------------------------------------------------------------- NO vote on F03/0045. The unstated philosophy behind F03/0045 seems to be that the standard should not require any action on an assumed-size array which would need to be applied elementally to the whole array. This is consistent with other restrictions on assumed-size arrays (no whole array assignment, for example). In accordance with this philosophy, (1) types with ultimate allocatable components also need to be excluded from being INTENT(OUT) assumed-size, as procedure invocation in this case requires deallocation of all the allocated components. (2) polymorphic INTENT(OUT) assumed-size arrays should also be excluded, as they might have default initialisation or allocatable components. This is a NO vote rather than a COMMENT vote simply because I think it would be better to interpret INTENT(OUT) assumed-size arrays fully, and not just stop half-way. But that is a pretty soft "NO". ---------------------------------------------------------------------- NO vote on F03/0046. There is no rationale given for rejecting ultimate polymorphic pointers in common blocks. Perhaps the thought was that they MIGHT point to objects of non-SEQUENCE non-BIND non-default-intrinsic type, and that since such a pointer with that declared type would be disallowed, so should ultimate polymorphic pointers. This reasoning is inconsistent with the answer given in F03/0053, where (currently-disallowed) TYPE(C_PTR) pointers were added to the list of things allowed in common. However, a TYPE(C_PTR) might also point to an object of non-SEQUENCE non-BIND non-default-intrinsic type. ---------------------------------------------------------------------- NO vote on F03/0047. Many of the answers seem to be incorrect or unjustified, and the edits are deficient and in poor style. Answer 4(c) is, I believe, incorrect. It is certainly inconsistent with the philosophy of the type extension facility in Fortran 2003. Question 4: (a) Are the A and MOLD arguments of the intrinsic function EXTENDS_TYPE_OF permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on their types refer to their declared types or dynamic types? Answer 4: (a) Yes. (b) No. (c) The requirements refer to the dynamic type. - This answer would imply that the EXTENDS_TYPE_OF intrinsic is unsafe to use on unlimited polymorphic arguments, because it could give type errors at runtime. This is something that we have strenuously tried to avoid in the type extension facility (as shown by the provision of such things as the SELECT TYPE construct). - Furthermore, the requirements CANNOT be satisfied by a disassociated or unallocated unlimited polymorphic, because such an entity has NO DYNAMIC TYPE. (The Result Value clause makes it clear that support for these was intended.) Therefore the requirements are, in fact, faulty. The answer should be (c) The requirements refer to the declared type, but are faulty in that they do not take unlimited polymorphic pointers into account. Edit: [316:16,17] Change "an object of extensible type" to "an object that is unlimited polymorphic or of extensible declared type". Answer 5(b) is not justified by the current text in the standard, and I see no reason to create such a requirement. Question 5: (a) Are the TSOURCE and FSOURCE arguments of the intrinsic function MERGE permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on the types of the arguments refer to their declared types or dynamic types? (d) If either argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Answer 5: (a) Yes. (b) Yes. - There is no justification, and no need, for this unnecessary restriction. Not only is it unnecessary, it inhibits use of MERGE when some variables are polymorphic. If the requirements refer to both the declared type and the dynamic type, that is sufficient to make MERGE useful. (c) The requirements refer to both the declared type and the dynamic type. - I agree that this should be the case. (d) In this case, the result is polymorphic. If the arguments are unlimited polymorphic, then the result is unlimited polymorphic and its dynamic type is the same as that of the arguments. Otherwise, the declared and dynamic types of the result are the same as those of the arguments. - And this answer should be that if BOTH arguments are polymorphic, the result is polymorphic. If only one is polymorphic, the result need not be as the declared and dynamic type are known to be one and the same. Similar considerations lead me to question answer 7(b) and 7(d), 8(b) and 8(d), 13(b) and 13(d). Answer 9(c) is deficient and contradicted by the (currently faulty!) text of the standard, in the same way that answer 4(c) is: Question 9: (a) Are the A and B arguments of the intrinsic function SAME_TYPE_AS permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on their types refer to their declared types or dynamic types? Answer 9: (a) Yes. (b) No. (c) The requirements refer to the dynamic type. - The requirements CANNOT refer to the dynamic type because a disassociated unlimited polymorphic does not have one. - The standard does not mention unlimited polymorphics in this subclause; that is because the result for a disassociated unlimited polymorphic is rather obvious (follows directly from the existing text) and does not need to be a special case. - The requirement "of extensible type" is faulty and should be repaired in the same way as EXTENDS_TYPE_OF. Answer 11(b) is not justified by existing text in the standard, and violates TRANSFER requirements. Question 11: (b) Is the MOLD argument of the intrinsic function TRANSFER permitted to be polymorphic? Answer 11: (b) No. - This contradicts [356:30-33] which requires, e.g. that (given suitable types and sizes) "... the value of TRANSFER(TRANSFER(E,D),E) shall be the value of E". Re the EDITS. I strongly object to the addition of these two tables to the standard. They are ad hoc and help no-one to decide whether a function that is not in these tables (e.g. the many vendor-extension intrinsics) should accept polymorphic arguments or not. Instead, the rules which underlie these tables must be exposed. For example, "An actual argument to an intrinsic function may be polymorphic only if the corresponding dummy argument accepts values of any type." and one could follow it up with something like: "If the result of an intrinsic function is specified to have the same type as that of one of its arguments, the result is polymorphic if and only if that argument is polymorphic, and is unlimited polymorphic if and only if that argument is unlimited polymorphic. In both cases the dynamic type of the result is that of the actual argument." Furthermore, I even more strongly object to arbitrary additional conditions on the dummy arguments of some functions being placed separately from the description of those functions. This just means the reader has to jump around inside the document quite unnecessarily. If clarifying text is required (as it doubtless is) in specific cases when it is not clear which of the dynamic and declared types is being referenced, I think there are two reasonable choices: (1) specify a rule like the above which allows the reader to deduce the answer, and which is extensible to new intrinsic functions, or (2) clarify the text in the function in question Or possibly even both if that is warranted. Addition of an ad hoc list of functions and arguments is unsatisfactory in this regard. ---------------------------------------------------------------------- NO vote on F03/0053. The answer to this interp is inconsistent with the answer to F03/0046, as explained in my comment on the latter. The discussion states: 1. It was intended that the behaviour of these types be similar to that of user-declared derived types in all respects except that they interoperate with C pointer types rather than C struct types. That would appear to be the case whether they have the BIND attribute or not, so this does not help to explain the U-turn. User-defined types are permitted not to have the BIND attribute. As well as the two cases cited in the question, there are special conditions in a pointer assignment statement (7.4.2) if either the pointer or the target has the BIND attribute. This does not seem to cause a problem whether these types have the BIND attribute or not. Also, there is a restriction on types with the BIND attribute in a SELECT TYPE statement (8.1.5). This is not a "new" point at all, merely a consequence of whether or not these types are extensible. There is no technical reason for these types not to be extensible - unlike SEQUENCE and BIND(C) types these types are in fact unique and therefore suited for extensibility. In summary, there appears to no technical justification and several non-sequiturs in the rationale. We should not reverse one of the provisions of the standard without good cause. .................................................................................. .................................................................................. John Reid Comment re F03/047 David has pointed out that F03/047 says 'insert new section 13.2 at 292:18+' but this is after the current 13.2 and before the current 13.3. In any case, the massive amount of renumbering in section 13 is really not appropriate in a corrigendum. I suggest that the edit commence: [292:18+] Before section 13.3, insert a new subclause 13.2.3: 13.2.3 Polymorphic intrinsic function arguments and results .................................................................................. .................................................................................. David Muxworthy Comment on F03/0047 I agree with John Reid's comment: the new subclause should be 13.2.3.