From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Fri Aug 24 03:16:10 2012 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id EE0953568FD; Fri, 24 Aug 2012 03:16:09 +0200 (CEST) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 1252 seconds by postgrey-1.34 at www5.open-std.org; Fri, 24 Aug 2012 03:16:08 CEST Received: from nag-j.co.jp (nag-j.co.jp [111.68.142.10]) by www.open-std.org (Postfix) with ESMTP id AE30135671C for ; Fri, 24 Aug 2012 03:16:07 +0200 (CEST) Received: from Maru6 (218-42-159-105.cust.bit-drive.ne.jp [218.42.159.105]) (authenticated bits=0) by nag-j.co.jp (8.14.5/8.14.5) with ESMTP id q7O0t88E062141 for ; Fri, 24 Aug 2012 00:55:12 GMT (envelope-from malcolm@nag-j.co.jp) Message-ID: <672F36BD25D04D8E804FC5C75E705D71@Maru6> From: "Malcolm Cohen" To: "WG5" References: <20120817095648.607253568FA@www.open-std.org> In-Reply-To: <20120817095648.607253568FA@www.open-std.org> Subject: Re: [ukfortran] (SC22WG5.4723) WG5 letter ballot on N1929 Date: Fri, 24 Aug 2012 09:55:09 +0900 Organization: =?UTF-8?B?5pel5pysTkFH?= MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Sender: owner-sc22wg5@open-std.org Precedence: bulk >Please answer the following question "Is N1929 ready for forwarding to WG23 >as the Fortran Annex to TR 24772?" in one of these ways. > >1) Yes. >2) Yes, but I recommend the following changes. >3) No, for the following reasons. >4) Abstain. No, because (a) the document is far from ready, with many technical and editorial mistakes having been pointed out by others; (b) the WG23 schedule does not need our input so urgently. Additional comments. A. Looking at Fortran.3.1 >The Fortran type system is a strong type system consisting of the type, the >kind, and in most circumstances, the rank, of a data object. The rank is not part of the type in Fortran. >The kind of an entity is a parameterization of the type. I do not know what this is trying to say, but it is false. Some types have more than one type parameter (e.g. CHARACTER) and indeed PDTs can have more than one "kind" parameter. Some entities have no kind at all (e.g. derived types with no kind type parameter). >Objects of the same type that differ in the value of their kind parameter(s) >differ in representation, and therefore in the limits of the values they may >represent. This is false. There is no such requirement on intrinsic types to differ in this way, and it is trivially false for (e.g.) TYPE t(k) INTEGER,KIND :: k REAL c END TYPE >A processor must support two kinds of type real and must support a complex kind >for every real kind that it supports. This is ambiguous (exactly two or at least two?). Either "must" -> "is required to" (not "shall"), or reword as a statement of fact instead of a requirement, e.g. like "A conforming processor supports at least two kinds of type real and a complex kind corresponding to each supported real kind." >Among the numeric types, coercion may result in a loss of information or a >wrong result. ... >if an integer variable with a large value is assigned to an integer variable >whose range do not include the value, the result is wrong. Ungrammatical and untrue. A program that does this does not conform to the Fortran standard. (The preceding sentence is also untrue, this one is just easier to see.) A processor is not required to detect such violations, and may do anything. >Objects of derived types are considered to have the same kind when their type >definitions are the same instance of text (which may be distributed among >program units by module use). Untrue. >(Sequence types and bind(c) types represent a narrow exception to this rule but >they are not generally used This assertion is false. Yes, the majority of derived types used are extensible types, but sequence and bind(c) are very commonly also used. >Operators applied to derived types must be explicitly coded by the programmer. I don't know why this is saying "operators", when "operations" is clearly what is intended. There is no "the programmer". Try "Other than default assignment, each operation on a derived type is defined by a procedure." >These explicitly coded procedures can contain whatever checks are needed. Overly casual language. And why "can contain"? This is meaningless blather. One could just as well write "These procedures can contain the complete works of Shakespeare.". Were you not intending to make a recommendation? And without my change immediately above, "procedures" are suddenly appearing with no antecedant; with my change above, this should begin "Such a procedure ...". And What does "whatever checks are needed" mean? This is less than meaningless blather. >In addition to the losses mentioned in Clause 6, Clause 6 of which document? (Perhaps the WG23 base document, in which case this form is correct, but if the Fortran standard is meant then the full reference needs to be given.) > assignment of a complex entity to a real entity results in the loss of the > imaginary part. No data is lost. All this separate witter about assignment and operations should just talk about conversions instead: converting complex to real necessarily produces a value with no imaginary part, but it is not "lost". >Assigning from an object of extended type to one of base type may also incur >loss of data. No data is lost. It is still there. >Intrinsic procedures may be used in declarations to supply desired kind values. "Intrinsic functions may be used in constant expressions that calculate desired kind type parameter values." B. Re Van Snyder's suggestion of blanket changing "must" to "shall"; instead, some/many/most/all of these should be reworded as statements of fact about conforming processors and programs. When that is not appropriate or would leave to clumsy wording, "must"->"is required to" might be sufficient as an indication that the requirement is required by some other document than the one being read (I will have to think about this a bit more). In any case, the document currently does not contain the word "shall", and this is good because this document is not a standard that should be attempting to place requirements on Fortran programs. Cheers, -- ................................Malcolm Cohen, Nihon NAG, Tokyo.