chris@spock (Chris Ott) (03/30/88)
lamaster@ames.arpa (Hugh LaMaster) writes: > 3) Fortran is not a bad programming language, even for systems programming. Baloney. I've done systems programming in Fortran before, with the best compiler I've ever worked with. It stinks. C is FAR better for systems programming. > Now C bigots will note that C has modules and internal procedures, and, yes, > it does have advantages as a system implementation languages. But, for a > Fortran replacement it is hopeless. The syntax is confusing and more error > prone than Fortran, but even worse, because C doesn't have dynamic array > dimensioning you can't use it for separately compiled libraries like > Linpack. When was the last time you programmed in C? If I remember correctly, C does have dynamic array dimensioning. I can't say for sure because I don't often use arrays with more than one subscript. Not only that, but C, with its alloc() and free() routine can dynamically allocate memory while the program is running, something I've never seen Fortran do. > Fortran is intrinsically neither more nor less portable than C. Not intrinsically, but in practice, C is a lot more portable than Fortran. I've had no trouble transporting C programs between UNIX machines and very little trouble transporting them between non-UNIX machines. I have never been able to transport a Fortran program without doing a lot of work. > Thousands > of Fortran programmers have run Linpack programs on their machines with > no modifications. And thousands of C programmers continue to write code > which depends on the existence of data types of certain sizes ( e.g. 16 bit > ints), on machine dependencies such as byte order, and indeed on how the > compiler will allocate the fields in a structure (just like the infamous > Fortran equivalence!)... Come on, this is true of ANY language, including both C and Fortran. Good programmers know how to account for these differences. Look at GNU Emacs, for example. This program runs on many different machines and all that needs to be changed is a few lines. It's so easy, even a beginner can do it. I know, because I did it when I was a beginner. C even helps you out with the sizeof() function, which Fortran doesn't have. Now, don't get me wrong: I'm not completely knocking Fortran. It's just that there are a lot of things that C does better. Sure, if you're doing computation, Fortran is better. It has intrinsic math functions that can be easily converted into in-line code, rather than using function calls, like C. It also has the exponentiation function (**) that C doesn't have. It has the complex variables that C doesn't have. Finally, yes, Fortran is just as portable as C when you are ONLY doing computation. Once you get out of the computational domain, however, Fortran just doesn't cut it. I used to do a lot of work with character strings in Fortran. Most compilers I've worked with don't even handle the substring operations defined by the Fortran 77 standard. Let's face it: strings were an after thought in Fortran and they are inadequate, at best. I/O isn't standard, either. I have never seen two compilers whose options lists for OPEN, READ, WRITE, and CLOSE were the same. Even the I/O itself isn't done the same: Sun Fortran is the only one I know that writes the record length at the beginning and the end of an unformatted record. In C, this is all under user control. Well, that's my two cents. Any comments or flames? Oh, I almost forgot. Please redirect any responses to this article to comp.lang.fortran. The comp.arch people are beginning to get upset, for good reason. ------------------------------------------------------------------------------- Chris Ott Computer-Aided Engr. Lab The right half of the brain controls the University of Arizona left half of the body. This means that only left handed people are in their right mind. Internet: chris@spock.ame.arizona.edu UUCP: {allegra,cmcl2,hao!noao}!arizona!amethyst!spock!chris -------------------------------------------------------------------------------
ok@quintus.UUCP (Richard A. O'Keefe) (03/30/88)
In article <497@amethyst.UUCP>, chris@spock (Chris Ott) writes: > lamaster@ames.arpa (Hugh LaMaster) writes: > > Fortran replacement it is hopeless. The syntax is confusing and more error > > prone than Fortran, but even worse, because C doesn't have dynamic array > > dimensioning you can't use it for separately compiled libraries like > > Linpack. > > When was the last time you programmed in C? If I remember correctly, C > does have dynamic array dimensioning. K&R C hasn't got dynamic array dimensioning, and neither has dpANS C, but the GNU C compiler from the Free Software Foundation. However, see the book "Numerical Algorithms in C", which is now out. I regard the techniques they use as unpleasant hacks, but you _can_ get the job done. > > of Fortran programmers have run Linpack programs on their machines with > > no modifications. And thousands of C programmers continue to write code > > which depends on the existence of data types of certain sizes ( e.g. 16 bit > > ints), on machine dependencies such as byte order, and indeed on how the > > compiler will allocate the fields in a structure (just like the infamous > > Fortran equivalence!)... Writing numerical code that will run under a variety of machines is not a trivial problem in any language. You might like to look at the ELEFUNT package. I have seen source code for a couple of statistics packages written in Fortran, and they made their code "portable" by writing their own equivalent of C's preprocessor. Much of the portability of Linpack comes from riding on the back of the Basic Linear Algebra Subroutines, so that a lot of nasty machine-dependent stuff (much of the actual numerical computations) is concealed. > WRITE, and CLOSE were the same. Even the I/O itself isn't done the same: Sun > Fortran is the only one I know that writes the record length at the beginning > and the end of an unformatted record. In the B6700 MCP, this was FILETYPE=6 ("Fortran Linkword"). I thought it was fairly common: how else are you supposed to be able to seek in such a file? With the size at each end of the record, you can move forwards AND backwards a record at a time.
lindsay@K.GP.CS.CMU.EDU (Donald Lindsay) (03/31/88)
ENOUGH ! Get this dreck off comp.arch ! -- Don lindsay@k.gp.cs.cmu.edu CMU Computer Science
chris@spock (Chris Ott) (03/31/88)
ok@quintus.UUCP (Richard A. O'Keefe) writes in response to my article: >> WRITE, and CLOSE were the same. Even the I/O itself isn't done the same: >> Sun Fortran is the only one I know that writes the record length at the >> beginning and the end of an unformatted record. > > In the B6700 MCP, this was FILETYPE=6 ("Fortran Linkword"). I thought it > was fairly common: how else are you supposed to be able to seek in such a > file? With the size at each end of the record, you can move forwards AND > backwards a record at a time. I never said it was a bad idea. I just said it wasn't standard. Most Fortrans I know don't do this. It was just one example of how non-standard Fortran I/O can be. If anybody wants more examples, I can dig them up. The point of my article was: Fortran should be used for certain problems and C should be used for other problems. Each language has its own domain. It bothers me when people start saying that some language is the best for everything. ------------------------------------------------------------------------------- Chris Ott Computer-Aided Engr. Lab "Blessed is he who is rich in spirit, University of Arizona for he shall make dough." Robert Heinlein Internet: chris@spock.ame.arizona.edu UUCP: {allegra,cmcl2,hao!noao}!arizona!amethyst!spock!chris -------------------------------------------------------------------------------
eugene@pioneer.arpa (Eugene N. Miya) (03/31/88)
In article <502@amethyst.UUCP> chris@spock.ame.arizona.edu (Chris Ott) writes: > The point of my article was: Fortran should be used for certain problems >and C should be used for other problems. Each language has its own domain. It >bothers me when people start saying that some language is the best for >everything. The problem comes with domains like the following: my office mate gets back from a conference on sparse matricies. Fortran isn't as good as certain other languages for the expression of the data structure. What do you do? 1) Mix <generic other language> and Fortran? 2) code purely in one language and live with deficiencies? 3) code in assembly language and hide these are a function or subroutine call in your favorite langauge? From the Rock of Ages Home for Retired Hackers: --eugene miya, NASA Ames Research Center, eugene@ames-aurora.ARPA "You trust the `reply' command with all those different mailers out there?" "Send mail, avoid follow-ups. If enough, I'll summarize." {uunet,hplabs,hao,ihnp4,decwrl,allegra,tektronix}!ames!aurora!eugene
jlg@a.UUCP (Jim Giles) (03/31/88)
In article <497@amethyst.UUCP>, chris@spock (Chris Ott) writes: > > > When was the last time you programmed in C? If I remember correctly, C > does have dynamic array dimensioning. I can't say for sure because I don't > often use arrays with more than one subscript. Not only that, but C, with > its alloc() and free() routine can dynamically allocate memory while the > program is running, something I've never seen Fortran do. 1) C has a VERY bad syntax for multidimensioned arrays. Most systems programmers don't need them, so they don't care. Few scientific programs go WITHOUT at least one multidimensional array. Fortran looks much better in this regard (literally LOOKS better). 2) C doesn't really have arrays at all - they get turned into pointers immediately. This failing was the subject of an article by no less than P. J. Plauger a short time back (Programming Faux Pas, _Computer Language_, April 1987). 3) Most Fortran environments have a way of dynamically allocating memory. Some use pointers, others have a language extension, others simply use out-of-bounds array subscripting. Fortran 8x requires this capability. > > Not intrinsically, but in practice, C is a lot more portable than Fortran. > I've had no trouble transporting C programs between UNIX machines and very > little trouble transporting them between non-UNIX machines. [...] I've never had any trouble transporting Fortran either. I just don't use any features that I know don't port well, and porting is no problem. C is the same - most C programmers quickly learn which things don't port well and simply don't use them! Don't chalk something up as a feature of the language when it's really due to familiarity of the programmer. > Oh, I almost forgot. Please redirect any responses to this article to > comp.lang.fortran. The comp.arch people are beginning to get upset, for good > reason. > No!! don't forward to comp.lang.fortran!! Forward to comp.lang.religion if you must :-). comp.lang.fortran is NOT the place to discuss the deficiencies of C as a scientific language (or its advantages either). J. Giles Los Alamos
jlg@a.UUCP (Jim Giles) (03/31/88)
Please don't follow-up on this subject. A discussion of the merits (or demerits) of C don't belong in comp.lang.fortran. Just because the word FORTRAN is in the subject line, doesn't mean that the subject really has something to do with Fortran. J. Giles Los Alamos
seibel@cgl.ucsf.edu (George Seibel%Kollman) (03/31/88)
In article <499@amethyst.UUCP> chris@spock.ame.arizona.edu (Chris Ott) writes: > >lamaster@ames.arpa (Hugh LaMaster) writes: > > Once you get out of the computational domain, however, Fortran just >doesn't cut it. I used to do a lot of work with character strings in Fortran. >Most compilers I've worked with don't even handle the substring operations >defined by the Fortran 77 standard. Let's face it: strings were an after >thought in Fortran and they are inadequate, at best. Maybe this is a case of "that was then and this is now"... I do a lot of string manipulation in fortran, I couldn't live without it. I've run the same string manipulating code on Macs and Crays, and a lot of machines in between, and it worked. Those compilers you mention that can't handle substrings are either broken or they aren't Fortran 77. (Is there a legal subset-language without substrings?) I think fortran 77 has gotten a bad rap on strings; I've been told on a number of occasions that Fortran "can't do" string manipulations that I do all the time with standard ANSI Fortran 77! I'm not talking about hideous bit-pushing hacks, I'm talking portable code. Now if I could just treat a file as a byte stream... George Seibel UC San Francisco
willis@auvax.UUCP (Tony Willis) (04/01/88)
I think you people who were debating the relative merits of FORTRAN vs C
should go off and learn PL/1! Let's face facts: PL/1 offers pretty well
all the features of C (bit manipulations, dynamic memory allocation,
string handling, pointers, etc) that C lovers
would claim FORTRAN lacks; on the other hand PL/1 offers
all the features of FORTRAN (complex arithmetic, wide range of math
functions) that FORTRAN lovers would claim C lacks.
Soo, how come PL/1 never became more popular (at least in North
America - it did become fairly popular in Europe where it was designed).
The answer would seem that a language which has "everything" just
becomes so large and bulky that good compilers were difficult to
design and implement. Too bad: I've used Pl/1 on a number of engineering
projects and I kind of liked it.
No flames please :-)
Tony Willis
Athabasca University ...{ubc-vision,ihnp4}!alberta!auvax!willis uucp
Box 10,000 usercdir@ualtamts BITNET
Athabasca, Alberta TOG 2R0
Canada (403) 675-6221 mcdonald@uxe.cso.uiuc.edu (04/02/88)
>legal subset-language without substrings?) I think fortran 77 has gotten >a bad rap on strings; I've been told on a number of occasions that >Fortran "can't do" string manipulations that I do all the time with >standard ANSI Fortran 77! I'm not talking about hideous bit-pushing hacks, >I'm talking portable code. Now if I could just treat a file as a byte >stream... Fortran 77 DOES have one VERY serious problem with strings: it is impossible to initialize them with non-printing characters. You can, of course, kludge it by installing things in after initialization: character*3 escseq data escseq/' [C'/ ... escseq(1:1) = char(27) Having to do this is just plain stupid: character constants SHOULD have been treated somewhat like C does, with escape sequences: /027, although maybe with the requirement that the escapes have a fixed length, or be terminated by another /. This is fixed in Fortran 88. Doug McDonald .... Now a satisfied C programmer, except for (Ugh!) multidimensional arrays.
chris@mimsy.UUCP (Chris Torek) (04/02/88)
In article <584@auvax.UUCP> willis@auvax.UUCP (Tony Willis) writes: >I think you people who were debating the relative merits of FORTRAN vs C >should go off and learn PL/1! Let's face facts: PL/1 offers pretty well >all the features of C ...; on the other hand PL/1 offers all the features >of FORTRAN .... >Soo, how come PL/1 never became more popular (at least in North >America - it did become fairly popular in Europe where it was designed). Because it also offers all the features of many other things: >The answer would seem that a language which has "everything" just >becomes so large and bulky that good compilers were difficult to >design and implement. Probably true. Perhaps more important, however, is that the language is so large that very few people become well versed in all of it. (Quick, what happens if I convert a FIXED BINARY(12,5) to a FIXED DECIMAL(8,7) [if I got the syntax right; I have never used PL/I, just a subset, and only twice or so]? How about `DO I=1, I=5'?) What happens is that people pick a subset of PL/I and write in that subset; different people have different subsets and find they are unable to maintain each others' code. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
gil@limbic.UUCP (Gil Kloepfer Jr.) (04/02/88)
In article <502@amethyst.UUCP> chris@spock.ame.arizona.edu (Chris Ott) writes: > The point of my article was: Fortran should be used for certain problems >and C should be used for other problems. Each language has its own domain. It >bothers me when people start saying that some language is the best for >everything. Would some of you out there PLEASE listen to both Chris and myself for once. Somehow I my news thing-a-ma-gig program must have lost the original posting that prompted this C vs. FORTRAN discussion. What really blows my mind is that I started and ended this SAME discussion months ago in comp.os.vms. My conclusion was the same as Chris' -- I program in both FORTRAN and C, and although I find FORTRAN to be a little deficient when it comes to some applications -- mainly handling data of an unknown size (where you say to yourself "Gee, I wish I had malloc()...") -- I find FORTRAN to be pretty flexible for some really low-level kinds of stuff. On the other hand, I've also done some really kludgy things in FORTRAN (because I had to...) rather than do it in C much more elegantly. There really IS NO argument for FORTRAN vs. C. Really -- there isn't. Computer languages are TOOLS for getting a job done. You use the tools you have to solve a PROBLEM presented to you, both in a classroom or commercial environment. Those that are truly GOOD programmers will be able to solve the problem at hand with the tools they are given. Sometimes you don't have a choice to use C or FORTRAN, and now it is up to you as a programmer to solve the PROBLEM with the tools you have, as much of a pain as it is sometimes. All of the positive arguments -- presenting the features of your favorite language -- are absolutely right. However, nobody will rip FORTRAN, C, COBOL, BASIC, etc. off the face of the Earth because <insert favorite language here> does this, this, and that better than <insert most hated language here>. You do what you have to do. Enough already? Or do we see the need to beat this one to death again? +------------------------------------+----------------------------------------+ | Gil Kloepfer, Jr. | Net-Address: | | ICUS Computer Group, Systems Dvlp. | {boulder,ihnp4,talcott}!icus!limbic!gil| | P.O. Box 1 | Voice-net: (516) 968-6860 | | Islip Terrace, New York 11752 | Othernet: limbic!gil@icus.UUCP | +------------------------------------+----------------------------------------+
ok@quintus.UUCP (Richard A. O'Keefe) (04/02/88)
In article <584@auvax.UUCP>, willis@auvax.UUCP (Tony Willis) writes: > I think you people who were debating the relative merits of FORTRAN vs C > should go off and learn PL/1! Let's face facts: PL/1 offers pretty well > all the features of C (bit manipulations, dynamic memory allocation, > string handling, pointers, etc) that C lovers > would claim FORTRAN lacks; on the other hand PL/1 offers > all the features of FORTRAN (complex arithmetic, wide range of math > functions) that FORTRAN lovers would claim C lacks. > Soo, how come PL/1 never became more popular (at least in North > America - it did become fairly popular in Europe where it was designed). Oddly enough, I've only ever used PL/I on a Burroughs B6700, a PR1ME 400, and an IBM 4331, all of which were made in the USA. (I thought PL/I was derived from the "New Programming Language" designed by SHARE?) Which of the elementary transcendental functions present in Fortran is missing in C? C has everything described in Cody&Waite, and I thought they described everything required in Fortran. Fortran *does* have string handling (like PL/I's CHAR, rather than CHAR VAR). There is an extremely good reason for using C rather than PL/I, and it is the same reason that someone would use F77 rather than F8X: it is important for a programmer to be able to master his tools, and PL/I is extremely hard to understand. (Need I mention the 22/7 bug?) {It is very easy to _think_ you understand PL/I, but when you consider tasking, the 'abnormal' attribute, label parameters, ONSOURCE, ...} F77 has one extremely great virtue which almost compensates for its defects: ordinary mortals can master the whole language.
ashcraft@yale.UUCP (Cleve Ashcraft) (04/04/88)
In article <6702@ames.arpa>, eugene@pioneer.arpa (Eugene N. Miya) writes: > In article <502@amethyst.UUCP> chris@spock.ame.arizona.edu (Chris Ott) writes: > > The point of my article was: Fortran should be used for certain problems > >and C should be used for other problems. Each language has its own domain. It > >bothers me when people start saying that some language is the best for > >everything. > > The problem comes with domains like the following: my office mate gets > back from a conference on sparse matricies. Fortran isn't as good as > certain other languages for the expression of the data structure. What > do you do? 1) Mix <generic other language> and Fortran? 2) code purely > in one language and live with deficiencies? 3) code in assembly language > and hide these are a function or subroutine call in your favorite > langauge? > From the Rock of Ages Home for Retired Hackers: > > --eugene miya, NASA Ames Research Center, eugene@ames-aurora.ARPA I just got back from the same conference. There was very interesting debate on this topic. The bottom line is that no one is content with the language choice. Given a choice a lot of people would work in C for all their numerical applications, but Cray supports Fortran, and there is so much other code out there to be used with it. Having done research in sparse matrix methods the past several years, I've written a lot of code in Fortran targeted for the Crays. Now that I am back in academia, I can write in whatever language I choose, and it is strictly C. My applications deal with portions of matrices (triangular or trapezoidal data structures) so I rarely see any need for doubly indexed arrays. Graph theory has more clarity in C than Fortran. Calling sequences shrink due to structures. No more DO loop labels. I think the most positive result of Fortran 8X is to make more people program in C. If only the C standards committee can keep from screwing up that language. --Cleve Ashcraft ashcraft@yale.arpa
mrm@sceard.UUCP (M.R.Murphy) (04/05/88)
In article <847@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >In article <584@auvax.UUCP>, willis@auvax.UUCP (Tony Willis) writes: >> I think you people who were debating the relative merits of FORTRAN vs C >> should go off and learn PL/1! Let's face facts: PL/1 offers pretty well [more stuff deleted...] > [more stuff deleted...] >There is an extremely good reason for using C rather than PL/I, >and it is the same reason that someone would use F77 rather than F8X: >it is important for a programmer to be able to master his tools, and >PL/I is extremely hard to understand. (Need I mention the 22/7 bug?) >{It is very easy to _think_ you understand PL/I, but when you consider >tasking, the 'abnormal' attribute, label parameters, ONSOURCE, ...} >F77 has one extremely great virtue which almost compensates for its >defects: ordinary mortals can master the whole language. PL/I has lots of different ways of saying the same thing. So does C. So does F77. PL/I is available on machines from not so very many manufacturers. C is available on machines from very many manufacturers. F77 (or F66) is available on LOTS of machines from LOTS of manufacturers. I have two 60000+ line systems written in PL/I that I would like to port to machines other than the IBM Series/1 for which they were written in Pl/I (with a compiler that runs in a 26kb partition :-). Any suggestions? Will I design any other large systems with PL/I as the implementation language and use all the neat features of the language to make the code short, readable, and non-portable? Not likely, even though I liked the language. -- Mike -- Mike Murphy Sceard Systems, Inc. 6353C El Camino Real Carlsbad, CA 92009 ARPA: sceard!mrm@nosc.MIL BITNET: MURPHY@UCLACH UUCP: ucsd!sceard!mrm INTERNET: mrm%sceard.UUCP@ucsd.ucsd.edu
jlg@a.UUCP (Jim Giles) (04/05/88)
> [...] > I think the most positive result of Fortran 8X is to make more > people program in C. If only the C standards committee can keep > from screwing up that language. > I've read the proposed C standard. It fixed much of what I consider bad about the C language. But it doesn't fix enough. I don't like C at a fundamental level (I don't like expression languages). It would take a lot to interest me in it. Still, comp.lang.fortran is NOT the place to discuss it. Also, in spite of the fact that the committee probably went to far with some parts of Fortran 8x (and not far enough with other parts), I still like it better than I do C. J. Giles Los Alamos
hirchert@uxe.cso.uiuc.edu (04/06/88)
>Soo, how come PL/1 never became more popular (at least in North >America - it did become fairly popular in Europe where it was designed). >Tony Willis Different people will give you different answers, but the thing that soured a lot of people on PL/I in this environment was its arithmetic rules. In attempting to combine the arithmetic rules of FORTRAN and COBOL, PL/I often produced nasty and unintuitive results. The classic that I remember was the statement DO I = 1 TO 10/2; The details are more than I want to present here, but the result was that 10/2 was converted to FIXED BINARY(31,34), shifting all significant bits off the end of the word and causing the loop not be executed at all. Except for this kind of arithmetic problems, I was usually able to live comfortably with the fact that I didn't know (or want to know) all of PL/I. Even if the arithmetic were fixed, I probably wouldn't choose PL/I today because its pointers are weakly typed and I find that a bit too dangerous for my tastes. Kurt W. Hirchert National Center for Supercomputing Applications
jlg@a.UUCP (Jim Giles) (04/12/88)
> Fortran 77 DOES have one VERY serious problem with strings: it > is impossible to initialize them with non-printing characters. You can, > of course, kludge it by installing things in after initialization: > > > character*3 escseq > data escseq/' [C'/ > > ... > escseq(1:1) = char(27) Why not do: character*3 escseq parameter (escseq=char(27)//'[C') This is Fortran 77 standard. Or, if you insist that escseq needs to be a variable, then do: character*3 escseq,pescsq parameter (pescsq=char(27)//'[C') data escseq/pesc/ This also is standard Fortran 77. This second is admittedly clumsy, but it works. Note that the 'fix' for this problem in Fortran 8x is not very popular (Object-Oriented Data statements (5.2.6.2)). J. Giles Los Alamos
jlg@a.UUCP (Jim Giles) (04/12/88)
In article <50500045@uxe.cso.uiuc.edu>, hirchert@uxe.cso.uiuc.edu writes: > Even if the arithmetic were fixed, I probably wouldn't choose PL/I today > because its pointers are weakly typed and I find that a bit too dangerous for > my tastes. > Boy, you must REALLY dislike C if the slightly weak typing on PL/I pointers puts you off. If you like C you should find some other reason to dislike PL/I - or maybe you should decide that you like it after all. Anyway, this discussion REALLY doesn't belong on comp.lang.fortran (as I've said before). J. Giles Los Alamos
hirchert@uxe.cso.uiuc.edu (04/12/88)
>Why not do: > character*3 escseq > parameter (escseq=char(27)//'[C') >This is Fortran 77 standard. Or, if you insist that escseq needs to be a ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ No, it's not. FORTRAN 77 allows only operators in PARAMETER statements. The extension to allow intrinsic functions is in Fortran 8x. >variable, then do: > character*3 escseq,pescsq > parameter (pescsq=char(27)//'[C') > data escseq/pesc/ >This also is standard Fortran 77. This second is admittedly clumsy, but >it works. Note that the 'fix' for this problem in Fortran 8x is not very >popular (Object-Oriented Data statements (5.2.6.2)). e.g. data (escseq=char(27)//'[C') Note that the syntax is entirely analogous with that of the PARAMETER statement. Note also that the current draft of Fortran 8x offers yet another (even less popular) alternative: character(3),data::escseq=char(27)//'[C' >J. Giles >Los Alamos Kurt W. Hirchert National Center for Supercomputing Applications
hirchert@uxe.cso.uiuc.edu (04/13/88)
>In article <50500045@uxe.cso.uiuc.edu>, hirchert@uxe.cso.uiuc.edu writes: >> Even if the arithmetic were fixed, I probably wouldn't choose PL/I today >> because its pointers are weakly typed and I find that a bit too dangerous for >> my tastes. >> >Boy, you must REALLY dislike C if the slightly weak typing on PL/I pointers >puts you off. If you like C you should find some other reason to dislike >PL/I - or maybe you should decide that you like it after all. "Slightly weak"? PL/I allows me to use any pointer variable in conjunction with any based variable. There is no syntactic indication of whether this is a match or mismatch because there is no nominal type associated with the pointer. In C, I can bypass the default strong typing with a cast, but this at least gives me an explicit syntactic indication that I'm playing games. >Anyway, this discussion REALLY doesn't belong on comp.lang.fortran (as I've >said before). True, but our sites uses notes rather than news, so I have no convenient way to direct my response (or subsequent followups) to another newsgroup. Sorry. >J. Giles >Los Alamos Kurt W. Hirchert National Center for Supercomputing Applications
root@mfci.UUCP (SuperUser) (04/14/88)
Expires: Sender: Followup-To: Distribution: Keywords: In article <563@a.UUCP> jlg@a.UUCP (Jim Giles) writes: }> Fortran 77 DOES have one VERY serious problem with strings: it }> is impossible to initialize them with non-printing characters. You can, }> of course, kludge it by installing things in after initialization: }> }> }> character*3 escseq }> data escseq/' [C'/ }> }> ... }> escseq(1:1) = char(27) } }Why not do: } character*3 escseq } parameter (escseq=char(27)//'[C') } }This is Fortran 77 standard. Or, if you insist that escseq needs to be a }variable, then do: } character*3 escseq,pescsq } parameter (pescsq=char(27)//'[C') } data escseq/pesc/ } }This also is standard Fortran 77. This second is admittedly clumsy, but }it works. Note that the 'fix' for this problem in Fortran 8x is not very }popular (Object-Oriented Data statements (5.2.6.2)). } }J. Giles }Los Alamos Rubbish. Neither of your examples are standard Fortran 77. The standard clearly states, in section 6.2.3, that a character constant expression may NOT contain function references. It doesn't matter if the arguments are constants and the functions are intrinsics. True, most Fortran compilers allow the examples you've shown, but they are most certainly not standard Fortran 77. (By the way, your second example has a typo, /pesc/ should be /pescsq/)
jlg@a.UUCP (Jim Giles) (04/14/88)
In article <337@m3.mfci.UUCP>, root@mfci.UUCP (SuperUser) writes: > > Rubbish. Neither of your examples are standard Fortran 77. The standard > clearly states, in section 6.2.3, that a character constant expression > may NOT contain function references. It doesn't matter if the arguments > are constants and the functions are intrinsics. [...] Whoops, sorry - quite right. Fortran 8x will allow intrinsic functions in constant expressions but not Fortran 77. That's what I get for not reading the next page! This is certainly an 8x feature that no one will object to. (Note - most Fortran compilers already allow some subset of intrinsics to be used in constant expressions. CHAR() is one of the ones usually allowed because it's easy to do at compile time. I actually did check my original code sequences on a few compilers before I submitted!) Actually, most of the vendors on the committee probably DO object to the new 8x feature. Some of them don't have compile-time access to the run-time math library. oh well... J. Giles Los Alamos
bill@hcx2.SSD.HARRIS.COM (04/18/88)
jlg@a.UUCP writes: > This is certainly an 8x feature that no one will > object to. Don't bet on this. > Actually, most of the vendors on the committee probably DO object to the > new 8x feature. Some of them don't have compile-time access to the run-time > math library. oh well... One can always get access, but do users want to pay the price? Consider that FORTRAN 8x increases the size of the runtime library significantly, so the compiler is going to be substantially bigger just from that effect alone (not counting the increase in size due to more language features). I think it is quite possible that a complete implementation of FORTRAN 8x will be impossible on most micros, just due to memory limitations. Consider, for example, that the compiler must have a version of SIN() for every precision the compiler supports. This could be significant on a machine that fully supports IEEE floating point. Now add to this COS(), ATAN(), etc. Do you want your FORTRAN compiler to take tens of Mbytes of YOUR memory?
bobal@microsoft.UUCP (Bob Allison) (04/21/88)
In article <44400019@hcx2> bill@hcx2.SSD.HARRIS.COM writes: > >One can always get access, but do users want to pay the price? Consider >that FORTRAN 8x increases the size of the runtime library significantly, >so the compiler is going to be substantially bigger just from that effect >alone (not counting the increase in size due to more language features). >I think it is quite possible that a complete implementation of FORTRAN 8x >will be impossible on most micros, just due to memory limitations. > >Consider, for example, that the compiler must have a version of SIN() for >every precision the compiler supports. This could be significant on a >machine that fully supports IEEE floating point. Now add to this COS(), >ATAN(), etc. Do you want your FORTRAN compiler to take tens of Mbytes >of YOUR memory? Hi Bill, gotten any tickets in that new car of yours? (Shelby Daytona) ;-) S Well, my personal position (this must be stressed that this is not the official position of my employer: we ain't got one yet, so there), is that I am worried about this very issue. I feel that compile-time overhead will be more like an Ada compiler than a FORTRAN 77 compiler, and I notice how few PC Ada compilers there are, and how some of them come with extended memory boards. My personal opinion is that it will be really difficult to compile a real FORTRAN 8X program which utilizes a lot of the spiffy features in 640K. In addition I can practically guarantee that any use of a Fortran 8X feature, even to perform something which could also be done easily with some set of FORTRAN 77 features, will execute slower than before (for instance, the array stuff vs. DO loops). So I am really worried that Fortran 8X is going to come out and all the sudden everyone is going to be very surprised at the results, which is one of the reasons I've gone through this long (boring) discussion. If this is really what people want, that is fine with me: I just don't want to be given grief about it later when this is what you get. So anyway, does anyone on the net do any FORTRAN programming on a PC? Bob Allison "Desperado, why don't you come to your senses?..."
jlg@a.UUCP (Jim Giles) (04/22/88)
In article <1405@microsoft.UUCP>, bobal@microsoft.UUCP (Bob Allison) writes: > In article <44400019@hcx2> bill@hcx2.SSD.HARRIS.COM writes: > > > >One can always get access, but do users want to pay the price? Consider > >that FORTRAN 8x increases the size of the runtime library significantly, > >so the compiler is going to be substantially bigger just from that effect > >alone (not counting the increase in size due to more language features). Why does a larger run-time library cause the compiler to be bigger? Surely the compiler need only recognize the NAMES and TYPE requirements for the intrinsics - then compile code that CALLS the stuff. The executable code will be larger (but only by as much as each intrinsic it calls). Note that this means that data initialization (constant valued intrinsic calls) is done partially at run-time. But you have to do that anyway - there may be more than one run-time library in the environment and the data initialization MUST be done with the same library that the executable code uses. > [...] In addition I can > practically guarantee that any use of a Fortran 8X feature, even to > perform something which could also be done easily with some set of FORTRAN 77 > features, will execute slower than before (for instance, the array stuff > vs. DO loops). > The array manipulation stuff in Fortran 8x should be UNIFORMLY faster than the equivalent DO loops. That is the reason all that stuff is being introduced. DO loops often hide the nature of a problem from the compiler and prevent it from finding the optimal code sequence. The new array manipulation primitives can be optimized easier. J. Giles Los Alamos
cdb@hpclcdb.HP.COM (Carl Burch) (04/25/88)
> > >so the compiler is going to be substantially bigger just from that effect > > >alone (not counting the increase in size due to more language features). > > Why does a larger run-time library cause the compiler to be bigger? Surely > > > features, will execute slower than before (for instance, the array stuff > > vs. DO loops). > > > The array manipulation stuff in Fortran 8x should be UNIFORMLY faster than > the equivalent DO loops. It looks like Mr. Giles is assuming shared libraries and sophisticated optimizing compilers; Bob and Bill seem to be worrying about PC-DOS* as it exists today (relatively dumb compilers and libraries on a small address space machine). I suspect that Fortran 8x is targetted above PC-DOS, but should work on more modern architectures. For one thing, Leahy (among others) says that it is just bearly possible to do the industry standard extensions to full FORTRAN 77 on PC-DOS - being concerned about doing F8x on it is an argument for nothing more than a few small extensions to F77. While some people favor that, I feel that being constrained by an architecture on its last legs (see OS/2 P.R. from a couple companies that shall go nameless) would be seriously irresponsible on the part of X3J3. The design rules (largely unwritten - F8x started before rationale documents were part of the standards process) that seem to be used : 1) Strict superset of the official F77 standard. 2) Assume reasonably modern compiler technology, but not state-of-the-art 1988. Explicitly not limited to that previously used in Fortran (e.g., procedure overloading isn't in anyone's Fortran but is no novelty in compiler labs). 3) Assume reasonably modern architecture in terms of runtime organization (i.e., stack/heap available) and address space. In the latter case, this is analogous to F77 - putting it on one of the early-60's machines I've heard of (~4k bytes total memory) would have been all but impossible. The stack/heap combination is required for practically all other languages - the flat world, sorry, memory model of FORTRAN prior to F8x is curious and fading away on even many Fortrans (Bell F77, HP Anything, others that prize inter-language calling compatibility). Both sides of this notes string seem to be arguing outside those lines, in opposite directions. Would you rather constrain the debate, or maybe both sides would prefer just to turn on me? :-) Sorry to interrupt a good argument - Carl Burch HP Fortran * PC-DOS is presumably a trademark of someone I'd prefer not to be sued by. H-P has no idea what I'm typing here - some people say I don't, either.
ssd@sugar.UUCP (Scott Denham) (04/26/88)
In article <1405@microsoft.UUCP>, bobal@microsoft.UUCP (Bob Allison) writes: < text deleted > > So I am really worried that Fortran 8X is going to come out and all the > sudden everyone is going to be very surprised at the results, which is > one of the reasons I've gone through this long (boring) discussion. If this > is really what people want, that is fine with me: I just don't want to be > given grief about it later when this is what you get. > > So anyway, does anyone on the net do any FORTRAN programming on a PC? > > Bob Allison Unquestionably YES, and lots of it!! Though I am in general favorably disposed towards many of the things in 8X, I too have difficulty seeing how these sorts of features can be "reasonably" implemented on a PC-class machine. We run applications on both IBM 3090 vector mainframes AND PC- based workstations ; not usually the SAME applications, but many, many of the support subroutines are common to both environments, and we are trying hard to make that even more the case. That leads to the proverbial rock & hard place dilemma - we want language features that help us to easily exploit the mainframe environment (E.G. vector syntax) but want to maintain PC portability. Our "standard" PC has become the 386-20 with 2 meg or so, so maybe technology will dig us out of this one before 8x digs us in any deeper!!
jlg@a.UUCP (Jim Giles) (04/27/88)
In article <6690016@hpclcdb.HP.COM>, cdb@hpclcdb.HP.COM (Carl Burch) writes: > > > >so the compiler is going to be substantially bigger just from that effect > > > >alone (not counting the increase in size due to more language features). > > > > Why does a larger run-time library cause the compiler to be bigger? Surely > > > > > features, will execute slower than before (for instance, the array stuff > > > vs. DO loops). > > > > > The array manipulation stuff in Fortran 8x should be UNIFORMLY faster than > > the equivalent DO loops. > > It looks like Mr. Giles is assuming shared libraries and sophisticated Not at all. Consider the following: A=B+C where A, B, and C are conformable 3-D arrays. The equivalent loops are: DO I=1,N DO J=1,M DO K=1,L A(I,J,K)=B(I,J,K)+C(I,J,K) END DO END DO END DO The inner loop setup is done M*N times and the J loop setup is done N times. In the 8x version, the compiler is free to choose the order in which the calculation is done (the compiler COULD rearrange the loops in the Fortran 77 version - but only a SMART compiler will be able to figure whether it's safe). In fact, the 8x version is free to notice that A, B, and C are contiguous (not RANGEs, for example) and the 8x compiler can do the statement as a single loop (or vector instruction if you have them). Even on the MS-DOS machines this saves M*(N+1)-1 loop setups! J. Giles Los Alamos
mcdonald@uxe.cso.uiuc.edu (04/27/88)
>It looks like Mr. Giles is assuming shared libraries and sophisticated >optimizing compilers; Bob and Bill seem to be worrying about PC-DOS* as it >exists today (relatively dumb compilers and libraries on a small address space >machine). I suspect that Fortran 8x is targetted above PC-DOS, but should >work on more modern architectures. For one thing, Leahy (among others) says >that it is just bearly possible to do the industry standard extensions to >full FORTRAN 77 on PC-DOS - being concerned about doing F8x on it is an >argument for nothing more than a few small extensions to F77. While some >people favor that, I feel that being constrained by an architecture on its >last legs (see OS/2 P.R. from a couple companies that shall go nameless) >would be seriously irresponsible on the part of X3J3. The design rules >(largely unwritten - F8x started before rationale documents were part of the >standards process) that seem to be used : I don't see how Fortran-anything can be "targeted" to a particular machine. It is supposed to be a general, standard, language for scientific and engineering use. Since the IBM PC is the most common computer in existence, and since lots of them are used for science and engineering, it essentially HAS to run on them. PC's have a BIG address space: 500K is not very constraining for a compiler, or at least it shouldn't be. Hasn't anybody ever heard of writing temporary files on disks? My PDP-11's get about 90% of Fortran 77 done in 45Kbytes! I find it IMPOSSIBLE to belive that 500K is any constraint at all, except of course on the brain-power requirements of compiler writers (and that it could slow down compiles a bit). Doug McDonald
bobal@microsoft.UUCP (Bob Allison) (04/27/88)
In article <6690016@hpclcdb.HP.COM> cdb@hpclcdb.HP.COM (Carl Burch) writes: > >It looks like Mr. Giles is assuming shared libraries and sophisticated >optimizing compilers; Bob and Bill seem to be worrying about PC-DOS* as it >exists today (relatively dumb compilers and libraries on a small address space >machine). I suspect that Fortran 8x is targetted above PC-DOS, but should >work on more modern architectures. For one thing, Leahy (among others) says >that it is just bearly possible to do the industry standard extensions to >full FORTRAN 77 on PC-DOS - being concerned about doing F8x on it is an >argument for nothing more than a few small extensions to F77. While some >people favor that, I feel that being constrained by an architecture on its >last legs (see OS/2 P.R. from a couple companies that shall go nameless) >would be seriously irresponsible on the part of X3J3. The design rules > Well, what I heard that Lahey said was that it is barely possible for a small company to start-up a FORTRAN 77 compiler: i.e. the investment and risk are both dangerously high. He felt that the cost and risk would be much higher for 8X and was concerned that only the big guys would get in on it. And I can hardly believe that DOS will not be around for at least a few more years. > [well-considered description of the de-facto rationale behind 8X] > >Both sides of this notes string seem to be arguing outside those lines, in >opposite directions. Would you rather constrain the debate, or maybe both >sides would prefer just to turn on me? :-) > >Sorry to interrupt a good argument - > Carl Burch > HP Fortran Well, I like to think that this is all pretty friendly and anyone who wants to will jump right in without fear of anybody getting nasty. Anyway, I know Carl personally, and I would never give such a personable guy a hard time publicly. Carl has made the (valid) point that we are talking at cross-purposes, but that is probably because I am not trying to attack specific features in this particular series of comments. My comments are based somewhat on the sad conclusion that just as people are beginning to be able to do some serious scientific programming in FORTRAN (or, at least some fast prototyping and debugging) on their PC's the door is going to be slammed in their faces with a new set of unstable, inefficient compilers which won't even work until they shell out a lot of bucks for new hardware and a new OS. And I personally believe we can come up with a very satisfactory new standard (with more than "a few small extensions") without having to go that far. Bob Allison