From owner-sc22wg5@open-std.org Sat Apr 30 05:40:28 2005 Return-Path: X-Original-To: sc22wg5-domo1 Delivered-To: sc22wg5-domo1@open-std.org Received: by open-std.org (Postfix, from userid 521) id D601711253; Sat, 30 Apr 2005 05:40:28 +0200 (CET DST) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from dkuug.dk (ptah.dkuug.dk [195.215.30.66]) by open-std.org (Postfix) with ESMTP id 8196CEADF for ; Sat, 30 Apr 2005 05:40:26 +0200 (CET DST) Received: from mail35.messagelabs.com (mail35.messagelabs.com [62.231.131.195]) by dkuug.dk (8.12.10/8.9.2) with SMTP id j3U3aSwE065485 for ; Sat, 30 Apr 2005 05:36:30 +0200 (CEST) (envelope-from malcolm@nag.co.uk) X-VirusChecked: Checked X-Env-Sender: malcolm@nag.co.uk X-Msg-Ref: server-22.tower-35.messagelabs.com!1114831973!27221439!1 X-StarScan-Version: 5.4.11; banners=nag.co.uk,-,- X-Originating-IP: [212.125.75.70] Received: (qmail 20976 invoked from network); 30 Apr 2005 03:32:53 -0000 Received: from smtp-1.star.net.uk (212.125.75.70) by server-22.tower-35.messagelabs.com with SMTP; 30 Apr 2005 03:32:53 -0000 Received: (qmail 26288 invoked from network); 30 Apr 2005 03:32:52 -0000 Received: from unknown (HELO nag.co.uk) (62.231.145.242) by smtp-1.star.net.uk with SMTP; 30 Apr 2005 03:32:52 -0000 Received: from brackley.nag.co.uk (brackley.nag.co.uk [192.156.217.21]) by nag.co.uk (8.9.3/8.9.3) with ESMTP id EAA01176 for ; Sat, 30 Apr 2005 04:32:44 +0100 (BST) Received: (from malcolm@localhost) by brackley.nag.co.uk (8.11.1/8.11.1) id j3U3dwc47660 for sc22wg5@dkuug.dk; Sat, 30 Apr 2005 04:39:58 +0100 (BST) (envelope-from malcolm) From: Malcolm Cohen Message-Id: <200504300339.j3U3dwc47660@brackley.nag.co.uk> Subject: Re: WG5 informal ballot on interps To: sc22wg5@dkuug.dk Date: Sat, 30 Apr 2005 04:39:58 +0100 (BST) X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () Sender: owner-sc22wg5@open-std.org Precedence: bulk Yes No Number Title -Y- --- F03/0030 IEEE divide by zero -Y- --- F03/0031 IEEE invalid -Y- --- F03/0032 Sign bit of IEEE NaN -Y- --- F03/0033 IEEE_VALUE() --- -N- F03/0034 IEEE_LOGB() -Y- --- F03/0035 IEEE_NEXT_AFTER() -Y- --- F03/0036 IEEE_REM() -Y- --- F03/0037 IEEE_RINT() -Y- --- F03/0038 IEEE_SCALB() --- -N- F03/0039 HYPOT() -Y- --- F03/0040 2.0+2.0 and IEEE -Y- --- F03/0041 IEEE halting and exceptions -Y- --- F03/0043 Passed-object arguments and procedure pointer components -Y- --- F03/0044 Implicit interfaces and conflicting references --- -N- F03/0045 Finalization and assumed- arguments with INTENT(OUT) --- -N- F03/0046 Unlimited polymorphic pointers in common blocks --- -N- F03/0047 Polymorphic arguments to intrinsic procedures -Y- --- F03/0052 ADVANCE= specifier in child data transfer statements --- -N- F03/0053 The BIND attribute for C_PTR and C_FUNPTR -Y- --- F03/0054 Denormal inputs to EXPONENT, FRACTION, and SET_EXPONENT -Y- --- F03/0055 Denormal inputs to SPACING and RRSPACING ====================================================================== 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. ---------------------------------------------------------------------- Cheers, -- ...........................Malcolm Cohen, NAG Ltd., Oxford, U.K. (malcolm@nag.co.uk) ________________________________________________________________________ This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________