From owner-sc22wg5@open-std.org Fri Feb 12 11:59:10 2010 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id 671F9C178DC; Fri, 12 Feb 2010 11:59:10 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from ns.nag-j.co.jp (218-42-159-107.cust.bit-drive.ne.jp [218.42.159.107]) by www2.open-std.org (Postfix) with ESMTP id 4A0E5C178DA for ; Fri, 12 Feb 2010 11:59:05 +0100 (CET) Received: from 218-42-159-108.cust.bit-drive.ne.jp ([218.42.159.108] helo=Marucomputer) by ns.nag-j.co.jp with smtp (Exim 4.50) id 1NftCG-0005d5-TR for sc22wg5@open-std.org; Fri, 12 Feb 2010 19:56:28 +0900 Message-ID: <144B25D35EC24E7C822D49E14814E573@Marucomputer> From: "Malcolm Cohen" To: "WG5" References: <20100209123609.439F7C178DC@www2.open-std.org> In-Reply-To: <20100209123609.439F7C178DC@www2.open-std.org> Subject: Re: [ukfortran] (SC22WG5.4168) WG5 letter ballot 7 on Fortran 2003interpretations Date: Fri, 12 Feb 2010 19:59:52 +0900 Organization: ??NAG MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_033E_01CAAC1D.F0CD5CE0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_033E_01CAAC1D.F0CD5CE0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit Attached is my provisional vote on the letter ballot. If time permits I will send additional votes on the ones I am currently not-voting on, but at the moment that seems unlikely. Cheers, -- ................................Malcolm Cohen, Nihon NAG, Tokyo. ------=_NextPart_000_033E_01CAAC1D.F0CD5CE0 Content-Type: text/plain; format=flowed; name="B1806.txt"; reply-type=response Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="B1806.txt" Yes No Number Title --- --- F95/0098 Are dummy functions returning assumed-length character legal? --- --- F03/0022 Coexistence of IEEE and non-IEEE kinds --- --- F03/0024 DEALLOCATE and array pointers --- --- F03/0034 IEEE_LOGB() -C- --- F03/0039 HYPOT() --- -N- F03/0063 Procedure pointers in BLOCK DATA program units --- --- F03/0071 Subroutine/function ambiguity in generics --- --- F03/0078 IEEE_SUPPORT_DATATYPE vs. mathematical equivalence --- -N- F03/0090 Polymorphic array constructors --- --- F03/0112 Attributes allowed for dummy arguments in defined assignments --- --- F03/0119 Elemental procedures and deferred length character components --- --- F03/0122 When do objects of sequence derived type have the same type? --- --- F03/0125 Definitions of EXTENDS_TYPE_OF and SAME_TYPE_AS --- --- F03/0126 References to VOLATILE variables in pure procedures --- --- F03/0127 Duration of procedure execution -C- --- F03/0129 C_LOC of character substrings --- --- F03/0130 Elemental specific intrinsic procedure characteristics --- --- F03/0131 SAVE attribute and EQUIVALENCE --- --- F03/0132 Unformatted i/o and private components --- --- F03/0133 Is unlimited polymorphic allowed in COMMON? --- --- F03/0134 Implicit typing of procedure pointers -C- --- F03/0135 Interaction between RESULT, recursion, and host generic --- --- F03/0136 Are subroutines distinguishable from arrays? --- --- F03/0137 Dummy procedure type compatibility --- --- F03/0138 External as -C- --- F03/0139 Functions returning procedure pointers --- --- F03/0140 Type of nested construct entities --- --- F03/0141 More than one specific interface for a procedure F03/0039 Comment. Can we not stop flogging this dead horse? I have no particular objection to John Reid's suggestion (though it requires changing the ANSWER and he didn't suggest wording for that), but why can't we just pass it and get rid of it? BTW, there was no IEEE HYPOT function until 2008, so comments about it not being the same are an elephant. F03/0063 NO vote. As Bill Long pointed out, this version leaves junk in the standard that thinks procedure pointers are allowed in COMMON blocks. Therefore the edits need to include [100:12-15] Delete "A procedure ... type parameters.". As for Bill's other suggestion re the definition of storage sequence, I don't think that matters since procedure pointers should not appear therein. OTOH, I have no objection to his suggested [416:23-24] "pointer"->"data pointer" and this is a certainly a good idea for F2008. I also agree with David Muxworthy's suggested change for the [98:21] edit (insert comma after allocatable). F03/0090 NO vote. Technical objection: 1. There is no edit that prohibits an array contructor ac-value from being unlimited polymorphic (i.e. CLASS(*)); we should state this directly, not make people infer it from more difficult rules. Proposed fix: [67:19+] Insert new constraint "An shall not be unlimited polymorphic.". Philosophical maunderings: 2. The answer impedes any future extension to allow polymorphic array constructors. The obvious way to prevent closing the door to future extension is to prohibit an ac-value from being polymorphic. Possible change: [67:19+] Insert different new constraint instead "An shall not be polymorphic.". 3. The situation in point 2 above is a bit unfriendly. Furthermore the comment that a function can be used to safely construct a polymorphic array is slightly naive: this requires separate processing for each potential dynamic type, so does not scale well. Possible response: Change the answer to allow polymorphic array constructors. F03/0129 Comment. John Reid writes: >The third edit should be >[396:5-7] Replace "; if ... one." with > ". If the type is character, it is interoperable if and only if > the value of its length type parameter is one." > Reason: It makes no sense to talk about the length type parameter > being interoperable. Au contraire, it makes reasonable sense given "A Fortran intrinsic type with particular type parameter values is interoperable ..." In any case the existing edit is superior, the suggested edit is contradicted by the existence of CHARACTER with KIND/=C_CHAR. F03/0135 Comment. I agree with David Muxworthy's change to the edit for [276:36+] ("the"->"that"). I agree with John Reid that the word "of" should be added after "scoping unit is" in both edits. F03/0139 Comment. The word "which" in the edit for [407:21-22] is correct. ===END=== ------=_NextPart_000_033E_01CAAC1D.F0CD5CE0--