From jwagener@ionet.net Thu Jan 30 21:56:04 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 VAA16669 for ; Thu, 30 Jan 1997 21:56:02 +0100 Received: from Zvyvogs (tulnas1-23.ionet.net [208.129.90.35]) by mail.ionet.net (8.8.4/8.7.3) with SMTP id OAA17831; Thu, 30 Jan 1997 14:53:52 -0600 (CST) X-Mailer: InterCon tcpCONNECT4 4.0 (Macintosh) MIME-Version: 1.0 Message-Id: <9701301502.AA46261@Zvyvogs> Date: Thu, 30 Jan 1997 15:02:46 -0600 From: "Jerrold L. Wagener" To: bob.thrun@wdn.com (BOB THRUN) Cc: sc22wg5@dkuug.dk Subject: Re: Fortran Wish List Content-Type: Text/Plain; charset=US-ASCII Content-Disposition: Inline Thanks for your comments, Bob. I will copy this reply, which includes the full text of what you sent me, to the standards committees, and any followup that you might send me. You are free to send a note directly to the committees; the email address is sc22wg5@dkuug.dk. I have a few responses, interspersed in your comments below. Jerry Wagener =================================== > > I read Van Snyders "Wish list for Fortran 2000". He suggests > that comments be sent to you. I don't know if that is really > the appropriate procedure, but nobody on comp.lang.fortran has > said otherwise. I'll have four sections to this message: > 1. Comments on some of Van Snyder's proposals. 2. Comments on > other issues inspired by his wish list 3. Comments about > the standardization process in general > > Comments on Van Snyder's Proposals > ---------------------------------- > > I won't go thru all of Van Snyder's proposals point-by-point. In > general, they are too compilcated and unnecessary. The Fortran > standard is already too complicated and in need of simplification. Simplification is one of my "hot buttons". I have proposed a KISS requirement (Keep It Simple, Stupid) for Fortran, but alas have not been able to garner much support for it. Everyone is for "simplicity", but there seems to be no agreement on what is "simple". From one perspective (e.g., some users), removing unnecessary statement ordering restrictions constitutes increased simplicity; from another perspective (e.g., some implementors), this makes things more complex. The whole issue is much more complicated than this simple (:-) example illustrates. Nobody has been able to describe an overall simplification paradigm that satisfies enough folks. -jlw > > An additional I/O clause ERRMSG=[character variable] for use with > IOSTAT= would be nice. The returned value could just be the error > message that would be printed if no IOSTAT had been used. The > returned value would, of course, be subject to truncatation. > > An ATAN(Y,X) function would be appropriate. > > What the heck is Van Snyder talking about about INCLUDE being > system defined? No change is needed. I'm not sure (I don't remember exactly what he said on this point), but it might have to do with file names. For example, the path syntax is different in dos than in unix. We have had other requests for making INCLUDE more portable in this regard, but nobody has come up with a suitable proposal (that is, suitable in the sense that it convinces enough people). -jlw > > I can see a use for an array of pointers to procedures. The obvious > way to make such an array in a Fortran-like manner is to relax > the restriction on the existing ASSIGN statement, which currently > only handles pointers to statements. > EXTERNAL SUB1, SUB2 > ASSIGN SUB1 TO K > CALL K > > The BLOCK and EXIT constructs sound like someone would rather > be programming in some language other than Fortran. > > The COME FROM statement was a joke circa 1970. I don't want it. > > Van Snyder proposes a bunch of restrictive attributes that seem to > be based on the philosophy that the more rules you make the > programmer follow, the less likely he is to make a mistake. I > totally disagree with this philosophy. (My way of making programs easy > to understand and maintain is to be as simple and straightforward > as possible. It is interesting to examine the programming styles > of skilled programmers who learned their craft before the > structured programming wave of the 1970s. They write good programs in > a style that does not follow the conventional preaching.) > > Van Snyder proposes a lot of flow control constructs that give me > the impression that he would rather be using a language other than > Fortran. > > A SWAP construct is unnecessary. I recall optimizing compilers > circa 1970 detecting that the TEMP variable was not used and doing > the swap in registers without putting anything into TEMP. > > SELECTED_INT_KIND has the problem that it does not match the > actual storage in most computers. For instance, if I want to count > to 20000, should I use SELECTED_INT_KIND(4), which would give me up > to 9999 on a system that uses BCD (Have there been any decimal > computers in the last 30 years?), or SELECTED_INT_KIND(5), which > would give me an INTEGER*4 on most byte-addressable systems? > Also, SELECTED_INT_KIND is too verbose and complicated. I would use > the simple and straightforward INTEGER*2, etc., that gives me exactly > what I want and expect on most computers. The exceptions could be > handled by conditional compilation. > Having specific upper and lower bounds would not be much of an > improvement. Programmers tend to specifiy and use what is > actually available. I have seen many Pascal programs that use a 0 > to 255 range even though the variable is only used to count to ten. > Van Snyder falls into the same mindset when he gives SELECTED_INT_ > KIND(0,65535) as one of his examples. If he really wants that, he > should specify UNSIGNED INTEGER*2. I am ambivalent about > UNSIGNED integers. I use INTEGER*2 variables as pointers into a > REAL array, Use of UNSIGNED integers would allow me to handle twice > as much data, but I might need to expand my program to handle three > or four times as much data. I have never thought about writing a > multiple precision arithmetic package, so I don't know the extent to > which unsigned variables are needed there. Well, I would have called it INT_KIND myself, which is less than half as long (:-). Seriously, in F90 you can do what you want: INTEGER(2). Okay, so you have to put the 2 in parens rather than after a star. But if the implementation provides that kind of integer then that's all you have to do. Frankly, I would prefer to say INTEGER(SHORT), so I guess it takes all kinds... Anyway, F90 already allows you to say it (pretty much) the way you want. I kind of like Van Snyder's suggestion because it lets me say it the way I want. (So you see, already we have a problem with "what is simple".) -jlw > > Comments on Issues Inspired by the Fortran 2000 Wish List > --------------------------------------------------------- > > Command Line Arguments > > The issue of command line arguments has generated a lot of traffic > on comp.lang.fortran. This is an obvious example of a simple and > easily remedied deficiency. I can think of several other deficiencies. > > Craig Dedo has proposed a GET_COMMAND_LINE subroutine. His proposal > is overly complicated. (Why do we get such complicated features? The > F90 INTEGER(KIND=SELECTED_INT_KIND(5)) vs. the common INTEGER*2 and > the DATE_AND_TIME subroutine are other examples.) I would keep > things simple and along the lines that are presently implemented in > many compilers. How about: > > FUNCTION IARGS() number of args in tail, 0 is command only, no tail > > SUBROUTINE GETARG(N, ARG, NC) N=0 is program name > ARG is character variable NC is > number of char, 0 if no Nth arg > > SUBROUTINE CMDLIN (TAIL, NC) TAIL is character variable > or CMDTAIL NC is number of char in tail > > We could dispense with the NC argument, but it saves a check for > string length. The character count also handles truncation and > trailing blanks. Under _no circumstances_ should any of these > return C-style zero-terminated strings. > > There should be subroutines to get separate arguments, which is > generally the most convenient, and to get the entire command line > tail, for applications that need to do special parsing. An > operating system that does not support all the command line functions > can return a zero count. > > I would shorten the name of the environment subroutine to GETENV and > make the status argument mandatory. I don't believe in optional > arguments. Command line arguments always get proposed and then seem to fade away when the crunch comes and some things have to be eliminated. I appreciate your suggestions, and the committee will see them before our meeting week after next. I suppose there is something wrong with this: why not arguments on the PROGRAM statement? -jlw > > > Carriage Control > > The current Fortran carriage control describes the behavior of > line printers that were attached to mainframes. It is amazing that > this specification exists in a language standard that tries to > be independent of hardware and operating systems. > > Some have proposed a new keyword, CARRIAGECONTROL=LIST, be added to to > the OPEN statement. This would be a mistake. Fortran historically > added only the record delimiters for the output device or operating > system. The earliest computers would write to tape with gaps > between records. With punched cards, each card was a separate > record. The CDC mainframes, which had no CR or LF characters, used > zero bytes to terminate a record. Output to a text file writes > the specified characters and them adds whatever the operating > system considers to be a text record terminator; LF for Unix, CR-LF > for MS-DOS, and CR for the Mac. Writing to a printer should be > no different. > > If the printer interprets column 1 in a certain way, then the > Fortran program may write the proper characters in column 1 and > the printer will handle it. If the printer does nothing special > with column 1, then it will be printed. It is the job of the printer > to do the interpretation, and not the job of the run-time library > to translate characters. The same holds true for sending FF characters > or escape sequences to a printer. > > > Conditional Compilation > > This would be a great advance toward portability. The language > should recognize that there are hardware and operating system > differences. > For instance, I have ten versions of a program that sends dot graphics > to a printer. Some sections of the program are generic and do not > care what the printer is. The only practical way to to make changes > to the generic sections is to run the source thru a preprocessor. I > would like this step to be integrated into the compiler and > standardized among different computers. > > The conditional compilation should allow logical expressions, such as > > IFDEF ((LASERJET .OR. DESKJET) .AND. (.NOT. COLOR)) THEN > > Textual substitution should not be allowed. This leads to code that > does not do what it says, because of some substitution in a header > file two levels away. The extreme example is the Obfuscated C contest. > > Specifying the use of the C proprocessor is not a satisfactory > solution. Not all Fortran users have C compilers. Not all C > compilers will write out processed text. Some integrated > programming environments send a file with a .FOR extension to the > Fortran compiler. > Some C preprocessors do C syntax checking. Some C preprocessors > remove white space. Conditional compilation has been proposed for "part 3" of the Fortran standard, and that work is well along. Check out papers 1243 and 1247 on ftp.ncsa.uiuc.edu/sc22wg5/ftp.nag.co.uk. -jlw > > > Comments about the standardization process in general > ------------------------------------------------------ > > The standards process is biased toward adding more and more features. > Each committee member has a few things that he particularly wants and > the usual bureaucratic compromise is to include them all. > > I get the impression that some of the Fortran committee members > would rather be programming some other language. I wish they would > and leave Fortran alone. Part of the problem is that academic types > do not find plain Fortran very interesting. > >