From owner-sc22wg5@dkuug.dk Mon Jun 16 23:02:22 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5GL2MPm003009 for sc22wg5-domo; Mon, 16 Jun 2003 23:02:22 +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 h5GL2FEc003004 for ; Mon, 16 Jun 2003 23:02:17 +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; Mon, 16 Jun 2003 13:59:38 -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 ; Mon, 16 Jun 2003 14:02:09 -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 h5GL2Cnl029182 for ; Mon, 16 Jun 2003 14:02:12 -0700 Received: (from maine@localhost) by altair.dfrc.nasa.gov (8.12.8/8.12.8/Submit) id h5GL2Ctj029178; Mon, 16 Jun 2003 14:02:12 -0700 From: Richard Maine MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="LC8+Uhf1pc" Content-Transfer-Encoding: 7bit Message-Id: <16110.12372.449019.241700@altair.dfrc.nasa.gov> Date: Mon, 16 Jun 2003 14:02:12 -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 --LC8+Uhf1pc Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Here is a draft of N1539, which is a revision of N1531. There are some significant technical changes relative to N1531, most notably that the allowable types of the argument are restricted. Again, this is a draft in order to allow possible additional changes. --LC8+Uhf1pc Content-Type: text/plain Content-Description: N1539.txt Content-Disposition: inline; filename="N1539.txt" Content-Transfer-Encoding: 7bit DRAFT 16 JUN 03 ISO/IEC JTC1/SC22/WG5 N1539 Storage size Richard Maine This is a revision of N1531 based on comments about it. This paper proposes that we replace NUMERIC_STORAGE_SIZE and CHARACTER_STORAGE_SIZE with an intrinsic function that can inquire about the size of any storage unit defined by the standard. I. Why do anything? 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. Many, if not most, implementations already have a similar 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). With NUMERIC_STORAGE_SIZE and CHARACTER_STORAGE_SIZE we would be adding a new feature that not only is obsolete now - it was obsolete two revisions of the standard ago. Those constants constants 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 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. II. Design considerations and alternatives 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 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. The allowable types of the argument are restricted to those types for which the standard already defines a storage size concept; this is all types that can be involved in storage association. In addition to the restrictions below, Van also suggested disallowing derived types with length type parameters (we do want to allow character though, so it would be important that this restriction be only on derived types). It appears to me that the draft already defines a storage unit for derived types with length type parameters and that therefore such a restriction is unnecessary here. It is possible that this is an error in the existing draft; if so, and if that is corrected, then I'd agree that such a restriction is appropriate here. I think the real question there is whether the existing draft is acceptable in defining such storage units. That is not fundamentally a question about this intrinsic; the intrinsic should just inquire about whatever the rest of the draft defines. It appears to me that the existing draft is in error in that it disallows BIND(C) types in storage association contexts. I believe that to be an unintentional oversight based on thinking that BIND(C) is a form of SEQUENCE. I think it quite important to be able to inquire about the size of BIND(C) types, so I have allowed them here, in anticipation of this oversight in the existing draft being fixed. If the committee truly believes that BIND(C) types should not be allowed in storage association contexts, then the "or have the BIND attribute" in the edits below should be deleted (but I really think that would be a mistake). For simplicity, this proposal depends on the declared type instead of the dynamic type. It turns out that the other restrictions rule out all the cases where there can be a difference, so this could be written either way (and could be changed in the future without incompatibilities). I'm willing to go either way on that. If this is changed to allow polymorphic arguments (in which case there could be a difference), we should still disallow unlimitted polymorphic arguments (becase they would need additional restrictions to make them work). I think the KIND argument unnecessary, but it was suggested and I go along with adding it for consistency. I'd also go along with deleting it. III. Edits [127:41+] Add list item (4a) the inquiry function STORAGE_SIZE, [298:19+] Add line "STORAGE_SIZE (X [, KIND]) Storage size in bits" [356:1+] Add section 13.7.115a STORAGE_SIZE (X [, KIND]) Description. Returns the storage size in bits for a nonpointer nonallocatable scalar of the declared type of X. Class. Inquiry function. Arguments. X may be of intrinsic or derived type. It shall not be polymorphic. If it is of derived type, that type shall be a SEQUENCE or interoperable type and shall have no allocatable ultimate components. If its type has any deferred type parameters, it shall be a pointer that is associated or an allocatable object that is allocated. It may be a scalar or an array. KIND (optional) shall be a scalar integer initialization expression. Result Characteristics. Integer scalar. If KIND is present, the kind type parameter is that specified by the value of KIND; otherwise, the kind type parameter is that of default integer type. Result Value. The result value is the size in bits of the storage unit (16.4.3.1) in a storage association context for a nonpointer nonallocatable scalar with the declared 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)." [362:28-33] Delete sections 13.8.2.3.1 and 13.8.2.3.2. {This assumes 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). --LC8+Uhf1pc Content-Type: text/plain; charset=us-ascii Content-Description: .signature Content-Transfer-Encoding: 7bit -- Richard Maine | Good judgment comes from experience; Richard.Maine@nasa.gov | experience comes from bad judgment. | -- Mark Twain --LC8+Uhf1pc--