Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!lanl!lambda!jlg From: jlg@lambda.UUCP (Jim Giles) Newsgroups: comp.lang.misc Subject: Re: Cheap implementations of languages (Re: Pointers and poor implementations (was: Re: JLG's flogging ...)) Message-ID: <14328@lambda.UUCP> Date: 10 Apr 90 23:14:47 GMT References: <15U2GTBggpc2@ficc.uu.net> Lines: 121 From article <15U2GTBggpc2@ficc.uu.net>, by peter@ficc.uu.net (Peter da Silva): > [...] > Well, I took my compiler construction course from the man who wrote the UNIX > fortran-77 compiler. He spent some time discussing the drawbacks of > Fortran to a compiler writer. I subsequently spent many pleasurable hours > playing with a public domain C compiler. I have never seen a public domain > Fortran compiler. It is completely irrelevant who tought your compiler construction course. Unless you can give _explicit_ features that are hard to implement in Fortran but are easy to implement in C, your argument is vacuous heresay. As for puiblic domain software - its worth about as much as you pay for it. There are few Fortran compilers in the public domain for PC's (I've seen two), because Fortran users are a demanding lot. They require performance. Only now do most of them feel that PC's are _starting_ to become _real_ machines. Up to now, the main market for PC's has been word processing and/or spreadsheet-business applications - neither one really in the class of problems that Fortran users are involved in. > [...] > If Fortran is so easy, where are the compilers for PCs? There are several > times as many C compilers available. That's the other major application for PC's - experimental and educational use. It is no coincidence that the the current fad language among comp- sci types is the most common on the inexpensive hardware. Up till about 3 years ago, the leader was Pascal (the previous fad language). It's interesting that in terms of language design, Pascal and C fall on the spectrum on opposite sides of Fortran - fads seem to seek the extremes. In light of the fact that PC's are not taken seriously by the Fortran community and the applications of PC's are not very Fortran-ish, it's surprising that there as many Fortran compilers as there are. It can't be THAT big a market. > [...] > C is not just a "little" easier to parse, it's a LOT easier to parse. Oh? Both have LR(1) grammars. The grammars are of about the same complexity. They both take about the same ammount of time to shove through the automatic parser generator. So what's the problem? Oh, Fortran's lexer is about half a page longer. Big deal. > [...] And > if you're just going to do a dumb code-generator the parser and symbol > table are about the only things to worry about. In which case, C is definitely harder since implementing a multilevel symbol table for C's nested scope rules MORE than offsets the lexer problem with Fortran. > [...] > You also brushed aside lots of problems with the Fortran compiler. How > about equivalences? Semantically, the same problems are presented by C's unions. > [...] How about commons? What about them? All data within common blocks are locally declared in every procedure. The _only_ differrence is that common references are relocated relative to a different block than static local variables are. > [...] How about compiling the good old > FORMAT statement (you can't just push it off to a subroutine, because you > need to have smarts in there to handle stuff like "WRITE (6,*) ...")? I usually parse it by calling the parse routine in the Fortran I/O library. The compiler only needs to know whether the format had an error or not. The compiler _could_ be built with the format grammar and on corresponding action routines. Besides, it's not particularly harder (or even different) than readf/printf formats in C. If your claim is that C is simple to implement, then the I/O support library must be something you claim is easy too. > [...] How > do you *prevent* arrays from being aliased (answer, you don't... not for a > dumb compiler)? How about ... Right, a dumb compiler lets aliased arrays be used unsafely - just like a C compiler. The difference is that it's illegal in Fortran, it's just dangerous in C. On a dumb compiler, there's no optimization anyway, so the Fortran aliased code breaks _exactly_ where the C code does. Of course, if your compiler _does_ do optimization, Fortran will run more efficiently because Fortran is willing to let illegal code break. > [...] > Fortran's completely ad-hoc nature really doesn't make it much fun. And C's completely ad-hoc nature _does_ make it fun? Remember, C is a language which started out with obvious syntax ambiguities (ie. A=-5;). And now you're trying to tell me that it's _NOT_ ad-hoc? Give me a break! > [...] > Tell you what... you write a PD Fortran compiler and we can compare it > in complexity with a PD C compiler and see who wins. No bet. I'm writing a compiler (but not for Fortran). I'm not going to make my compiler public domain (I intend to get paid for my work - or go bust and be unsuccessful :-). In terms of code speed, the Fortran would probably win. In terms of compiler complexity, they'd be about the same since any compiler I write will be based on a flexible compiler "skeleton" which could be used for most languages (Fortran, C, Pascal, etc.). The reason for this is that language design is a favorite study of mine - I want any compiler I write to be flexible enough to try out new features easily. In terms of popularity, the C compiler would win - until it's fad runs out. But, even then, the Fortran wouldn't be popular, some other fad language will take the spotlight. Languages are seldom popular for their technical merits (which is why I'm perfectly willing to consider the possibility that my Nemesis compiler will not be successful). If languages _were_ popular because of merit, I can think of a _lot_ of languages (some _very_ old) that deserve the spotlight more that C or Fortran (or Pascal, Modula, Ada, etc.). J. Giles