pack@acdpyr.ucar.edu (Dan Packman) (10/21/88)
I think many readers will agree it will take some time for 8x to
be approved as a standard, implemented by vendors, and actually used.
I would have been happy with an intermediate standard that tried to
do little but standardize often included extensions to f77 (ie,
looping via while, in line comments, include statements, namelist io,
and conditional assembly [with well known predefined constants for
machines and operating systems ala cpp]). We use a local pre-processor
called IFTRAN and with all its warts, it serves us well.
One addition to the language I would like would be a floating point
conversion intrinsic to and from IEEE floating point in direct analogy
to the network byte order macros such as htonl (host to network long)
that exist in the c world.
If we bit off a smaller piece for a standard, maybe we all could swallow it.
Dan Packman NCAR INTERNET: pack@acdpyr.UCAR.EDU
(303) 497-1427 P.O. Box 3000 CSNET: pack@ncar.CSNET
Boulder, CO 80307 DECNET SPAN: 9.367::PACKssd@sugar.uu.net (Scott Denham) (10/21/88)
In article <867@ncar.ucar.edu>, pack@acdpyr.ucar.edu (Dan Packman) writes: (Dan writes a very good case for an intermediate FORTRAN standard that would merely take care of "often included extensions") > > If we bit off a smaller piece for a standard, maybe we all could swallow it. > Dan Packman NCAR INTERNET: pack@acdpyr.UCAR.EDU In hindsight, it would seem that exactly such an intermediate step might have avoided the mess that the FORTRAN standard is in now. Had the committee started after the '77 standard with less ambitious goals, we would likely have had that intermediate standard some time ago and have been well on our way to the next one, which might not look too different from what is now being proposed as FORTRAN 9X (I've given up on the "8"). But to try to do that now would seem to be counterproductive; it would just land everybody back in the position of lobbying to make sure THEIR ffavorite bit of the 8X standard got included in the interim. Scott Denham Western Atlas International
khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) (10/22/88)
It appears that my last several postings have been eaten by the local buffer monster ;-> In article <2874@sugar.uu.net>, ssd@sugar.uu.net (Scott Denham) writes: > In hindsight, it would seem that exactly such an intermediate step might > have avoided the mess that the FORTRAN standard is in now. > No. The last couple of YEARS of commitee time dealt with this at GREAT length. There has been ballot after ballot on deleting "unnecessary features". EVERY FEATURE in f88 WAS DEMANDED BY ONE GROUP or ANOTHER. f88 is not "too" ambitious. If anything it is too conservative (now that we have abstract data types and overloading(*) what do we do about overloading IO ?)) (*) Many are claiming that ADT and overloading is "not fortran...etc". FORTRAN is supposed to be FORMula TRANslator. To illustrate why these features are useful for "real" applications... When I write U*D*U**T It is understood that this means multiply an upper triangular matrix by a diagonal matrix by a lower triangular matrix (basis of Kalman filtering) The "determinstic time step" of a kalman filter requires U*D = PHI*U*D where, by convention, UD contains the "factors" as a vector of length n*(n+1)/2. PHI, of course, is a full square matrix. With overloading, and ADT, I can define a datatype UD as a special case of an upper triangular matrix. Overload * so that a square matrix * a triangular matrix, returns a triangular matrix. Now the code looks like the algorithm! How do we do this in f77 call PHIU(PHI,MAXPHI,IRPHI,JCPHI,U,N,W,IMAXW) call WGSG(W,IMAXW,IW,JW,DW,F,V,U) Now which is closer to the formula ? Which will be easier to maintain ? With generics I can even make everything work for double precision, w/o changing the code. Is it really better to have call DPHIU() call DWGSG() Which features of the proposal do you want to drop, why, and what does it do to the consistency and expressive power of f88 ? Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus