From jwagener@ionet.net Sun Feb 16 22:47:31 1997 Received: from mail.ionet.net (ultra2.ionet.net [206.41.128.42]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id WAA11766 for ; Sun, 16 Feb 1997 22:46:45 +0100 Received: from Zvyvogs (tulnas1-13.ionet.net [207.204.119.25]) by mail.ionet.net (8.8.4/8.7.3) with SMTP id PAA25900; Sun, 16 Feb 1997 15:44:08 -0600 (CST) X-Mailer: InterCon tcpCONNECT4 4.0 (Macintosh) MIME-Version: 1.0 Message-Id: <9702161554.AA01469@Zvyvogs> Date: Sun, 16 Feb 1997 15:54:01 -0600 From: "Jerrold L. Wagener" To: Fred Marton Cc: "'vsnyder@math.jpl.nasa.gov'" , sc22wg5@dkuug.dk Subject: Re: F2000 Wish List : Default types used in intrinsics, plus ... Content-Type: Text/Plain; charset=US-ASCII Content-Disposition: Inline Fred, thanks for your note, which just showed up and was waiting for me when I returned from the WG5/X3J3 meeting last week. I wish we had had it last week, as it touches on some of the decisions made. See comments interspersed below, and I'll copy this reply to the committees. Jerry Wagener ================================ > Hi: > From an experience of writing computational intensive simulations with > a very high degree of user friendliness, where input interpretation > and error trapping is a considerable portion of the user > friendliness code, my initial wish list includes: > > 1. When using the Kind parameters with variables, I often ran into > the problem that intrinsic functions require default types. Also > when using non-default kind variables, the conversion and matching must > be observed carefully, a situation that begs hard to detect errors. > > Proposal a: Have a global directive (e.g. implicit none ) that sets > the kind of variables used in the program unit for each type. I have > no strong suggestion for a name, could be a IMPLICIT REAL_KIND( > kind_parameter ), > IMPLICIT INTEGER_KIND( kind_parameter ), Something like a subset of this was originally on the list for Fortran 2000 as a "minor technical enhancement", under the title "specified default precision". However, it was removed last week during the "requirements process"; I'm not sure why, other than that nobody had stepped up to "champion" it for the past couple of years. -jlw > > 2. On i/o errors, it is today a bit of spaghetti code to handle them. > I propose the expansion of the definition of err= , eor= and end= > where the standard allows to reference a statement label, also add > the name of a routine, and transfer occurrs to that routine on an > iostat not equal zero. The routine arguments to be ( iostat= > dummy1,[...dummy2],...) as many as should be specified. > > Proposal b: Add the capability on i/o statements to specify the name of > a routine where the standard allows now only a statement label. On > return the execution resumes on the statement following the i/o > statement. Point taken. Probably an even better way to handle these such I/O exceptions is with a coherent exception-handling facility. There will be such a facility for floating-point exceptions in Fortran 2000, but last week the committee elected not to generalize that to a wider class of exceptions, including I/O, inadequate storage, etc. A preliminary facilility of a more general nature was widely discussed 2-3 years ago, but alas was not acceptable to enough people. -jlw > > 3. It would be logically cleaner and faster if LOGICAL variables > were defaulted to 1 storage unit. Thisw would then require to define > also a SELECTED_LOGICAL_KIND( ). To continue with proposal a: > an IMPLICIT LOGICAL_KIND( kind_parameter ), > > Proposal c: Make Logical default type to be a 1 memory storage unit ( or > a terminology of "a single memory read/write" ) Interestingly enough, "packed LOGICAL" was discussed last week, but did not receive a high enough priority to be included in Fortran 2000. Different kinds of logical have been discussed often but, in my opinion, have never gotten enough support because of the insistance of some that it be a new BIT data type rather than a kind of logical. As for making a "1 bit" logical the default, that incurs compatibility problems that would have to be satisfactorily resolved; while not impossible, that is always very difficult. Finally, it probably is not feasible to force "1 bit" implementation, as Fortran has never specified the implementation details for any of its data types; the standard can only "suggest" such implementation. This is true even for a BIT data type. -jlw > > 4. As so much discussions has taken place with respect to single bit > data, I propose that two BIT types be added to the standard. > One bit type would be of fixed length, syntax akin to the CHARACTER > syntax BIT(len=1234) :: varname is a variable of 1234 bits of length > and has all the operations and intrinsics of logical variables > plus concatenation with other BIT variables. Arrays also allowed. > BIT( : ) :: varname is a variable length of bit type and has all > the operations and intrinsics of logical variables plus > concatenation with other BIT variables. Arrays not allowed. > > Proposal d: Add two new variable types, a fixed length BIT type and > a variable length BIT type. Expand the operators and intrinsics to > handle the BIT types.(note 1). BIT data type was considered last week and rejected; as you indicate, and as mentioned above, there is no clear consensus on what kind of BIT data type users need (probably both kinds, each by small constituencies). -jlw > > 5. Allow pointers to point to a substring of a character variable: > pointer => character( n:m) hmm... I'll probably get some mail on this one. I don't see in the F95 standard where this is disallowed. R736 and R737, together with the second constraint, seem to allow it. However, I'm not sure what "pointer result" is in the fifth constraint. You're probably right about this, but I can't confirm it on a quick reading. Perhaps you, or someone else, can set me straight. -jlw > 6. Add an attribute to character pointers to point to the same > substring, even when it moves do to adjusts, and concatenation > and assignments. Thus if p => char1( n:m) and then char1 = char2(: > s)//char1 thereafter p would be pointing to char( s+n:s+m ) > This attribute could be labeled CHARACTER, POINTER, AFFIXED :: In F90/F95 pointers are just "aliases", so I think this implies a more sophisticated pointer facility. (Or maybe this is why pointers to substrings are disallowed in the first place, if they are.) Again I'm going to have to bounce this one off the pointer police, by way of copy of this reply. -jlw > 7. Allow pointers to point to PARAMETERS Do you have some reason in mind? Off hand I would think that this might prevent implementing parameters as if they were simple macros, which is currently an allowed implementation. -jlw > 8. Allow pointers to point to sub-bits of BIT types. > > Proposal e: Augment the definition of pointers : Allow character > pointers to point to substrings of CHARACTER types ( and sub-bits of > BIT types ) Allow pointers to point to parameters > Add an AFFIXED attribute to a character (and bit ) pointer definition > > > I do hope you find these proposals worthy of scrutiny and discussion, > and acceptance into the list of proposals Certainly they are thought-provoking, and I wish we had had them for our meeting last week. Alas, I did not receive them in time. -jlw > > Fred Marton > > >