hallidayd@yvax.byu.edu (06/23/89)
Bob Corbett (corbett@beatnix.UUCP) in message <2724@elxsi.UUCP> laments: > The use of KIND selectors for integer types is distasteful, since a >range mechanism could provide the same capability in a portable way. However, >given that no similar mechanism will work for character, logical, and >floating-point data types, consistency argues for the use of KIND selectors >for integers as well. I wonder why KIND was introduced in the first place, unless there is some reason to have an all encompassing way of referring to data types (each data type having a unique, essentially arbitrary, integer designation that could possibly be used as a tag for message passing, so long as both sender and receiver have agreed on some such type designation). The natural designation for REAL and COMPLEX data types has already been recognized an PRECISION and EXPONENT_RANGE, the natural designation for CHARACTER data is LENGTH (the number of characters a string of this type can contain), and the natural designation for integers is a range (either specified by an INTEGER_RANGE the way EXPONENT_RANGE is specified, or as two integers specifying the lower and upper bounds). The only type that does not have a ``natural'' designation is LOGICAL. This is because the LOGICAL data type, normally, can only represent two states, .TRUE. and .FALSE. . A single bit would suffice to represent it, though not all machines can access a bit, or even a byte for that matter, in an efficient way. The most natural designation is probably PACKED and not PACKED, where the host compiler for the target machine interprets the PACKED designation simply to mean the user wants the LOGICAL variable to take as little room as possible or reasonable (or if the proposed standard is more restrictive than this, I yield to it). Therefore, if the standard will implement a range like designation for INTEGERs (and see to it that the CHARACTER designation is not called KIND but something like LENGTH) I will be quite happy to essentially ignore the machine dependent KIND---unless someone can give me a convincing argument as to *why* I should use it. _____________________________________ / David Halliday \ | | Happy computing B-) | Internet: hallidayd@yvax.byu.edu | | BITNET: hallidayd@byuvax | I am glad to see Fortran | Us Mail: BYU Physics Department | modernized a bit, but lets | 296 ESC | do it ``right'' | Provo, UT 84602 | \_____________________________________/
brainerd@unmvax.unm.edu (Walt Brainerd) (06/25/89)
In article <645hallidayd@yvax.byu.edu>, hallidayd@yvax.byu.edu writes: > Therefore, if the standard will implement a range like designation for > INTEGERs (and see to it that the CHARACTER designation is not called KIND > but something like LENGTH) I will be quite happy to essentially ignore the > machine dependent KIND---unless someone can give me a convincing argument > as to *why* I should use it. > You don't need to worry about the machine numbers for KIND of integer and real unless you want to. You can get default and you can specify range and precision, as in REAL (SELECTED_REAL_KIND (9, 70) X which gives X 9 digits of precision and a range to 10**70. This is not as beautiful as previously proposed, but does provide the functionality and avoids some problems. Character has TWO type parameters, LENGTH and KIND. LENGTH is as it always has been. You don't need to worry about kind unless you want to make sure the representation is something other than the default on your machine, e.g., ASCII, KANJI, or CHEMICAL. Walt Brainerd Unicomp, Inc. brainerd@unmvax.cs.unm.edu
hallidayd@yvax.byu.edu (06/27/89)
From message <172@unmvax.unm.edu> by Walt Brainerd (brainerd@unmvax.unm.edu) >You don't need to worry about the machine numbers for KIND of integer >and real unless you want to. You can get default and you can specify >range and precision, as in > >REAL (SELECTED_REAL_KIND (9, 70) X ^ missing a ) I presume? > >which gives X 9 digits of precision and a range to 10**70. >This is not as beautiful as previously proposed, but does provide >the functionality and avoids some problems. So we will be able to select KIND of integer by range? Is it something like SELECTED_INTEGER_KIND(lowest, highest) or some such? If so, I will be sufficiently happy (concerning this issue). _____________________________________ / David Halliday \ | | | Internet: hallidayd@yvax.byu.edu | | BITNET: hallidayd@byuvax | | Us Mail: BYU Physics Department | | 296 ESC | | Provo, UT 84602 | \_____________________________________/
brainerd@unmvax.unm.edu (Walt Brainerd) (07/01/89)
In article <657hallidayd@yvax.byu.edu>, hallidayd@yvax.byu.edu writes: > So we will be able to select KIND of integer by range? Is it something > like SELECTED_INTEGER_KIND(lowest, highest) or some such? If so, I will > be sufficiently happy (concerning this issue). > SELECTED_INT_KIND (5) gives a range _between_ -10**5 and 10**5, i.e. 5 digits. Walt Brainerd Unicomp, Inc. brainerd@unmvax.cs.unm.edu