From owner-sc22wg5@dkuug.dk Tue May 6 17:43:20 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h46FhKxU013171 for sc22wg5-domo; Tue, 6 May 2003 17:43:20 +0200 (CEST) (envelope-from owner-sc22wg5@dkuug.dk) X-Authentication-Warning: ptah.dkuug.dk: majordom set sender to owner-sc22wg5@dkuug.dk using -f Received: from mailhub.dfrc.nasa.gov (mailhub.dfrc.nasa.gov [130.134.81.12]) by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h46FhFEc013165 for ; Tue, 6 May 2003 17:43:16 +0200 (CEST) (envelope-from maine@altair.dfrc.nasa.gov) Received: from mail.dfrc.nasa.gov by mailhub.dfrc.nasa.gov with ESMTP for sc22wg5@dkuug.dk; Tue, 6 May 2003 08:41:52 -0700 Received: from altair.dfrc.nasa.gov ([130.134.20.211]) by mail.dfrc.nasa.gov (Post.Office MTA v3.5.3 release 223 ID# 0-71686U2500L200S0V35) with ESMTP id gov for ; Tue, 6 May 2003 08:44:04 -0700 Received: from altair.dfrc.nasa.gov (localhost.localdomain [127.0.0.1]) by altair.dfrc.nasa.gov (8.12.8/8.12.5) with ESMTP id h46Fi5Ec030543 for ; Tue, 6 May 2003 08:44:05 -0700 Received: (from maine@localhost) by altair.dfrc.nasa.gov (8.12.8/8.12.8/Submit) id h46Fi5o4030539; Tue, 6 May 2003 08:44:05 -0700 From: Richard Maine MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <16055.55365.347506.986880@altair.dfrc.nasa.gov> Date: Tue, 6 May 2003 08:44:05 -0700 To: sc22wg5@dkuug.dk Subject: Storage size X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Sender: owner-sc22wg5@dkuug.dk Precedence: bulk YAPFD. (Yet another paper for Dresden). -- Richard Maine | Good judgment comes from experience; Richard.Maine@nasa.gov | experience comes from bad judgment. | -- Mark Twain ----------------------------------------------------- Date: 6 May 03 To: WG5 From: Richard Maine Subject: Storage size In response to a public comment, paper J3/03-108r3 added three new named constants to ISO_FORTRAN_ENV. I have no objection to the addition of FILE_STORAGE_SIZE. However, for the other two, I strongly feel that this is something that we should do correctly if we are going to do it at all. We are adding a new feature that not only is obsolete now - it was obsolete two revisions of the standard ago. The proposed constants NUMERIC_STORAGE_SIZE and CHARACTER_STORAGE_SIZE would have been adequate for f77. As of f90, they are woefuly inadequate. Why are we adding new features to f2k that support only f77 code and are all but useless for code that follows most style recommendations for f90 code? Are we prepared to explain our answer to that question when it gets asked by users, as it most certainly will be? When that happens, don't expect me to defend the feature. I do not find the argument that "this is what someone asked for" to be very convincing. People ask for lots of things that they don't get. We need to apply our best judgement in answering requests - not just limit the answers to yes or no. In this case, a solution that I consider good is quite doable. We can do the job in a way that provides both the requested functionality and also use useful for newer coding styles. It isn't particularly difficult to do that. If we don't think this feature is worth the small amount of work to do that way, or if a majority thinks that it is harder than I do, then I don't think we should do it at all. I propose that we add the function below as a more complete solution for this useful functionality. Many, if not most, implementations already have a smilar function. I have avoided the most common current names for it specifically to avoid potential conflicts in points of detail....and that allows me to do one thing in what I consider to be a more robust way (we will return the size in bits instead of in octets). This function could be added either as an intrinsic or as a module procedure in ISO_FORTRAN_ENV. I came down slightly on the side of doing it as an intrinsic, but it was a close call. The edits below are for that approach. If a majority finds it more appropriate in the module, that is an easy change and one I'd find acceptable. Other choices for the function name would also be acceptable. The proposed function allows array arguments, but always returns the size of a scalar of the type. The standard adequately defines the storage requirements for arrays in terms of those for scalars, so I see no need for array-related functionality in this function. I consider the proposed function similar to the LEN intrinsic in this regard (LEN accepts array arguments, but returns the length of an element rather than the length of the whole array). The proposed function works on the dynamic type of its argument. An unpublished first draft used the declared type for simplicity, but I realized that handling len type parameters requires run-time evaluation in some cases anyway, so we might as well go with the dynamic type as slightly more flexible. It is not absolutely essential that polymorphic arguments be allowed at all. If that is deemed too much complication, we could prohibit them. But it seems to me that they do work out pretty well. The edits below delete the NUMERIC_STORAGE_SIZE and CHARACTER_STORAGE_SIZE constants, because the function is more general. If one wanted to have both the constants and the function, I wouldn't object too strongly. That wouldn't be my first choice, but it is well within bounds that I'd consider reasonable as a compromise. I. Addition of the function [127:41+] Add list item (4a) the inquiry function STORAGE_SIZE, [298:19+] Add line "STORAGE_SIZE (X) Storage size in bits" [356:1+] Add section 13.7.115a STORAGE_SIZE (X) Description. Returns the storage size in bits for a nonpointer scalar of the declared type of X. Class. Inquiry function. Argument. X may be of any type. It shall not be unlimited polymorphic. If it is an unallocated allocatable or a disassociated pointer, it shall have no deferred type parameters. It shall not be a pointer with undefined association status. It may be a scalar or an array. Result Characteristics. Default integer scalar. Result Value. The result value is the size in bits of the storage unit (16.4.3.1) for a nonpointer scalar with the dynamic type and type parameters of X. Example. STORAGE_SIZE(1.0) returns the number of bits in the numeric storage unit. [417:36-38] "The sizes...(13.8.2.3)" -> "The size of the file storage unit is given by the constant FILE_STORAGE_SIZE (13.8.2.3.3). The sizes of the character storage unit, numeric storage unit, and unspecified storage units can be determined using the intrinsic function STORAGE_SIZE (13.7.115a)." II. Deletion of the constants These edits assume that 13.8.2 has been simplified as described in part 1 of my paper titled ISO_FORTRAN_ENV. If that isn't done, then other trivial changes are needed in the sentence that forms the body of 13.8.2.3, and the 13.8.2.3.3 section heading should probably be deleted (or promoted). [362:28-33] Delete sections 13.8.2.3.1 and 13.8.2.3.2.