lagache@violet.berkeley.edu.UUCP (09/17/87)
Hello to everyone in FORTRAN land!
In our introductory FORTRAN classes we have just switched to the
f77 compiler. Our first assignment involves students deliberately
inserting errors in the code in order to gain familiarity with the
compiler's characteristics. This is fine when the teaching staff
understands the errors, but a few days ago I hit an error that I
couldn't!
PROGRAM PRACT
REAL NUM1,NUM2,SUM
WRITE(*,*) 'Enter two numbers to be added to each other:'
READ(*,*) NUM1, NUM2
SUM = NUM1 + NUM2
WRITE(*,*)
WRITE(*,*) 'The sum of the two numbers is : ',SUM
STOP
END
%f77 practice.f
practice.f:
MAIN pract:
Error on line 4 of practice.f: syntax error
Warning on line 9 of practice.f: local variable num2 never used
Warning on line 9 of practice.f: local variable read never used
^^^^
----------------------------------------------> ???? <---------
After some discussion with the staff, we concluded that
the assignment was being interpreted before the I/O statement,
but that doesn't give me much satisfaction.
My question to the SIG is does this sort of interpretation
represent a bug? I am no expert on FORTRAN compiler design, but
given this sort of funny business, I wonder what sort of weird
code would be passed on as correct!?!
Edouard Lagache
School of Education
U.C. Berkeley
lagache@violet.berkeley.eduanita@utastro.UUCP (Anita Cochran) (09/17/87)
In article <5117@jade.BERKELEY.EDU>, lagache@violet.berkeley.edu (Edouard Lagache) writes: > In our introductory FORTRAN classes we have just switched to the > f77 compiler. Our first assignment involves students deliberately > inserting errors in the code in order to gain familiarity with the > compiler's characteristics. This is fine when the teaching staff > understands the errors, but a few days ago I hit an error that I > couldn't! > PROGRAM PRACT > REAL NUM1,NUM2,SUM > WRITE(*,*) 'Enter two numbers to be added to each other:' > READ(*,*) NUM1, NUM2 > SUM = NUM1 + NUM2 > WRITE(*,*) > WRITE(*,*) 'The sum of the two numbers is : ',SUM > STOP > END > %f77 practice.f > practice.f: > MAIN pract: > Error on line 4 of practice.f: syntax error > Warning on line 9 of practice.f: local variable num2 never used > Warning on line 9 of practice.f: local variable read never used > ^^^^ > ----------------------------------------------> ???? <--------- > My question to the SIG is does this sort of interpretation > represent a bug? I am no expert on FORTRAN compiler design, but > given this sort of funny business, I wonder what sort of weird > code would be passed on as correct!?! > Edouard Lagache This is not the result of a bug in the compiler but a true error by you. On line 5 (which is what actually caused the error), you have the variable "sum" too far to the left (presummably your on purpose error) and the "U" is in the continuation statement column. Thus, the compiler interprets both lines 4 and 5 together as line 4. It scans along until it hits the equal and decides everything prior to that is the left hand side of the equation. The first problem it has, is that you have a "statement number" (s) in the middle of the equation, and an illegal statement number at that. Even if it discards that, it now has read(*,*)num1,num2m as the left hand side of the equation. It cannot figure out what to do with this. The only thing it can decide is that read must be an undeclared 2 dimensional array. Thus, it throws up its (figurative) hands and ignores statement 4/5 leading to the further errors. -- Anita Cochran uucp: {noao, ut-sally, ut-ngp}!utastro!anita arpa: anita@astro.as.utexas.edu snail: Astronomy Dept., The Univ. of Texas, Austin, TX, 78712 at&t: (512) 471-1471
peregier@watvlsi.UUCP (09/17/87)
In article <5117@jade.BERKELEY.EDU> lagache@violet.berkeley.edu (Edouard Lagache) writes: > PROGRAM PRACT > REAL NUM1,NUM2,SUM > WRITE(*,*) 'Enter two numbers to be added to each other:' > READ(*,*) NUM1, NUM2 > SUM = NUM1 + NUM2 > WRITE(*,*) > WRITE(*,*) 'The sum of the two numbers is : ',SUM > STOP > END >Error on line 4 of practice.f: syntax error >Warning on line 9 of practice.f: local variable num2 never used >Warning on line 9 of practice.f: local variable read never used The compiler is doing exactly what it is told. The fifth line has an entry in column 6 and therefore is a continuation line. The compiler treats the fourth and fifth lines as READ(*,*) NUM1, NUM2M = NUM1 + NUM2 which is a syntax error. I'm not going to try to guess exactly how the compiler parses this line, but when it does you get your error messages. Move line 5 to the right by two spaces and it works.
steved@sun.UUCP (09/17/87)
In article <5117@jade.BERKELEY.EDU> lagache@violet.berkeley.edu (Edouard Lagache) writes: > [ A FORTRAN program containing the invalid lines:] > READ(*,*) NUM1, NUM2 > SUM = NUM1 + NUM2 > [ Which produces the error messages] >Error on line 4 of practice.f: syntax error >Warning on line 9 of practice.f: local variable num2 never used >Warning on line 9 of practice.f: local variable read never used > ^^^^ >----------------------------------------------> ???? <--------- > > After some discussion with the staff, we concluded that > the assignment was being interpreted before the I/O statement, > but that doesn't give me much satisfaction. > ... > > Edouard Lagache > School of Education > U.C. Berkeley > lagache@violet.berkeley.edu The compiler's error message can best be uderstood by considering the statement as seen by the compiler because of the illegal continuation character. It sees: READ(*,*) NUM1, NUM2M = NUM1 + NUM2 Since FORTRAN keywords are not reserved, the compiler must determine from the context whether a particular sequence of characters is a keyword or variable. One way it does this is to scan the statement for an '=' not enclosed within parentheses. Since 'READ' is not a valid keyword starting a statement with an '=', it takes the read to be a variable. -- --------------------------- Steve Dever steved@Sun.COM or Sun Microsystems sun!steved
kent@xanth.UUCP (Kent Paul Dolan) (09/18/87)
In article <5117@jade.BERKELEY.EDU> lagache@violet.berkeley.edu (Edouard Lagache) writes: > > Hello to everyone in FORTRAN land! > > In our introductory FORTRAN classes we have just switched to the > f77 compiler. Our first assignment involves students deliberately > inserting errors in the code in order to gain familiarity with the > compiler's characteristics. This is fine when the teaching staff > understands the errors, but a few days ago I hit an error that I > couldn't! > > PROGRAM PRACT > REAL NUM1,NUM2,SUM > WRITE(*,*) 'Enter two numbers to be added to each other:' > READ(*,*) NUM1, NUM2 > SUM = NUM1 + NUM2 > WRITE(*,*) > WRITE(*,*) 'The sum of the two numbers is : ',SUM > STOP > END > >%f77 practice.f >practice.f: > MAIN pract: >Error on line 4 of practice.f: syntax error >Warning on line 9 of practice.f: local variable num2 never used >Warning on line 9 of practice.f: local variable read never used > ^^^^ >----------------------------------------------> ???? <--------- > > After some discussion with the staff, we concluded that > the assignment was being interpreted before the I/O statement, > but that doesn't give me much satisfaction. > > My question to the SIG is does this sort of interpretation > represent a bug? I am no expert on FORTRAN compiler design, but > given this sort of funny business, I wonder what sort of weird > code would be passed on as correct!?! > > Edouard Lagache > School of Education > U.C. Berkeley > lagache@violet.berkeley.edu Edouard, I can't promise this is exactly right, because I don't do the inside of FORTRAN (compilers), but I've used the outside (written FORTRAN programs) since 1961, so this is at least pretty close! First, it helps to understand that the error introduced concatinated most of line 5 to line 6, dropping either the S or the SU, depending on where column 6 (the continuation column) is in your listing. Second, it helps to remember that FORTRAN supports default typing, and so variables can be declared by being used, in leiu of any other declaration. Last, it helps a little to remember that FORTRAN deletes all spaces except the ones inside strings "before" parsing. As a result, the compiler saw something like: READ(*,*)NUM1,NUM2M=NUM1+NUM2 Following a usual compiler strategy, it threw away what it couldn't understand right then, giving READ(*,*)=NUM1+NUM2 and, deciding READ was an array being assigned to, generated a symbol table entry for it. Now, however, it still couldn't choke down the *,*. So, it tossed out the line, thereby deleting the only references to NUM2 and to the "variable" READ. Arriving at the end of the routine, it complained, self righteously, that you had never used this variable READ. Cascading, and progressively more meaningless, errors can happen to any compiler as the range of errors gleefully added by students exceeds the compiler writer's ability to forsee them. FORTRAN is better in this respect than many languages, because ends of lines naturally delimit statements, so the next line is a natural recovery point for the compiler. Free syntax, block structured languages, can easily spawn pages of errors because a single letter is omitted from a keyword (I saw this in a C program just yesterday), so count your blessings! ;-) More seriously, it is important that your students be exposed to this, so that they can learn to expect it, and to look for the first error, and remove it, before trying to cope with a long list of seemingly meaningless error messages. Sometimes "seemingly" = "really", and compilers, like snakes, should be trusted only when held down firmly with a forked stick. They otherwise have a tendency to turn upon and bite the unwary. I posted this (long winded) answer with the complete original posting in hopes some novices would find it of tutorial assistance. And, to abuse some more bandwidth, and leave you with a smile (read the book, it is worth the price just for the cover on the paperback), I present my latest .signature: Kent, the man from xanth. His expression lit up. "Hey, you wouldn't be a dope smuggler, would you?" Rail looked confused. "Why would anyone wish to smuggle stupidity when there is so much of it readily available?" -- Alan Dean Foster, GLORY LANE
normt@ihlpa.ATT.COM (N. R Tiedemann) (09/18/87)
In article <5117@jade.BERKELEY.EDU>, lagache@violet.berkeley.edu (Edouard Lagache) writes: > > PROGRAM PRACT > ... > READ(*,*) NUM1, NUM2 > SUM = NUM1 + NUM2 > ... > > Error on line 4 of practice.f: syntax error > Warning on line 9 of practice.f: local variable num2 never used > Warning on line 9 of practice.f: local variable read never used > ----------------------------------------------> ???? <--------- > After some discussion with the staff, we concluded that > the assignment was being interpreted before the I/O statement, > but that doesn't give me much satisfaction. > Edouard Lagache > lagache@violet.berkeley.edu Yes, that is the case, Since the two lines where combined with the S acting as a continuation character. The F77 compiler (and others) will scan a line looking for assignment statements first, if none found, then it will search for key words. This gives you the ability to use such words as read, write, etc. as variable names without compiler confusion. When compiler gives syntax error, other error messages are irrelevant. (Old Saying). This is true in Fortran, but boy is it true in any structured language. With a syntax error in C strange messages will appear 100's of lines later. Norm Tiedemann AT&T Bell Labs ihnp4!ihlpa!normt Naperville, IL 60566 "Just because we invented the stuff, doesn't mean we have to like it."
firth@sei.cmu.edu (Robert Firth) (09/22/87)
In article <5117@jade.BERKELEY.EDU> lagache@violet.berkeley.edu (Edouard Lagache) writes:
PROGRAM PRACT
REAL NUM1,NUM2,SUM
WRITE(*,*) 'Enter two numbers to be added to each other:'
READ(*,*) NUM1, NUM2
SUM = NUM1 + NUM2
WRITE(*,*)
WRITE(*,*) 'The sum of the two numbers is : ',SUM
STOP
END
%f77 practice.f
practice.f:
MAIN pract:
Error on line 4 of practice.f: syntax error
Warning on line 9 of practice.f: local variable num2 never used
Warning on line 9 of practice.f: local variable read never used
Could the problem be that the 'U' on line 5 is interpreted as a
continuation symbol? Hence the compiler thinks line 4 reads
READ(*,*)NUM1,NUM2M=NUM1+NUM2
This MIGHT cause it to think READ was an array, since the line
now appears to be an assignment statement.
However, does this really matter? A compiler whose error reporting
is this bad should not be lightly tossed aside - it should be thrown
with great force.ags@j.cc.purdue.edu (Dave Seaman) (09/23/87)
In article <2577@aw.sei.cmu.edu> firth@bd.sei.cmu.edu.UUCP writes: > READ(*,*)NUM1,NUM2M=NUM1+NUM2 > >This MIGHT cause it to think READ was an array, since the line >now appears to be an assignment statement. > >However, does this really matter? A compiler whose error reporting >is this bad should not be lightly tossed aside - it should be thrown >with great force. I am curious to know what you think adequate error reporting should look like for this statement. I suppose you could try something like: Line 4: Unexpected characters on left hand side of assignment statement. The actual message, on the other hand, is almost as good: > Error on line 4 of practice.f: syntax error Knowing that there is a syntax error on line 4, anyone who knows FORTRAN should be able to look at the line and see what the error is. I suspect what you are complaining about is the presence of the warning messages: > Warning on line 9 of practice.f: local variable num2 never used > Warning on line 9 of practice.f: local variable read never used Would you consider the compiler's error reporting to be "improved" if these warning messages had been suppressed? Why? Do you object to both warnings, or only the one that mentions the variable "read"? Why? -- Dave Seaman ags@j.cc.purdue.edu
firth@sei.cmu.edu (Robert Firth) (09/24/87)
In article <5307@j.cc.purdue.edu> ags@j.cc.purdue.edu.UUCP (Dave Seaman) writes: >In article <2577@aw.sei.cmu.edu> firth@bd.sei.cmu.edu.UUCP writes: > >> READ(*,*)NUM1,NUM2M=NUM1+NUM2 ... >>However, does this really matter? A compiler whose error reporting >>is this bad should not be lightly tossed aside - it should be thrown >>with great force. > >I am curious to know what you think adequate error reporting should look >like for this statement... (1) I would first expect the compiler to produce a listing with both line numbers and statement numbers. This alone would have alerted the user to the real problem (2) Secondly, I would expect the exact CHARACTER position to be given, of every fragment that the parser did not understand. Just giving a line number (and arguably the wrong line number) is unhelpful. In the above case, given the standard Fortran scansion technique, there should be carets (or whatever) pointing at the *,*, the N after the right parenthesis, and the comma after NUM1 (3) Thirdly, the compiler should ALWAYS report what class of statement it is confused by. Even "syntax error in assignment statement" would have been far more helpful here. This is because the usual way of scanning Fortran is first to classify the statement by heuristic techniques, and then to try to parse it rigorously. If an error causes the first action to go wrong, the parser can get some very strange ideas. As we see. (4) Fourthly, there should be an explanation for each detected error, saying why the compiler thinks it's an error. In the above examples, I would expect something like "illegal index expressions for array READ" "can't understand identifier after array reference" "left-hand side of assignment statement cannot be a list" These are still poor error messages, being compiler friendly rather than user friendly, but I've chosen messages that could be produced from the syntactic information readily available to the recogniser in question. (5) Finally, if the compiler is going to complain about unused variables, it should at least indicate where they were declared. Again, that is very helpful to the user; moreover, in this case it would have prevented the message about READ: since READ is undeclared, the error reporting code can discover for itself that the message is wrong, and suppress it. As a last point: compilers that do all the above exist, and exist in profusion. After using some of them, you might come to hold my view, that Unix is cursed with too much amateur software. (Or you might not; tastes vary)
kent@xanth.UUCP (Kent Paul Dolan) (09/26/87)
In article <2619@aw.sei.cmu.edu> firth@bd.sei.cmu.edu.UUCP writes: [gobs of great stuff pointing out why f77 error messages are inadequate] >As a last point: compilers that do all the above exist, and exist in >profusion. After using some of them, you might come to hold my view, >that Unix is cursed with too much amateur software. (Or you might not; >tastes vary) Oops. You were on a roll right up to here, then the hackles started to rise! ;-) I use a pretty substantial part of all of the utilities and languages provided with BSD4.3. Among the (education oriented) users of this system, I'm pretty sure over 90% are used regularly. I used to do a lot of commercial software buying, back when I was still working for a living, and if you had to pay for "professional" software to replace the stuff that comes bundled with Unix, 1) you would pay $0.5M to $1.3M for the OS with goodies, and 2) most of it would be in _worse_ shape. The up side of "amateur software" is that everybody gets a shot at finding and kicking out bugs, too (at least, everybody at sites with a source license), providing a much quicker path to (relatively) clean software. At commercial prices (the same compiler that can be had for $500 on a micro is suddenly worth $20,000 on a mainframe), educational institutions, the ones who supply the bulk of the cheap labor to upgrade and improve Unix, would not be able to afford the system at all, and so everyone who benefits would instead suffer. I also have a lot of love for _good_ commercial software; there's just so little of commercial software that is good, and such outrageous prices on all of it. Kent, the man from xanth. His expression lit up. "Hey, you wouldn't be a dope smuggler, would you?" Rail looked confused. "Why would anyone wish to smuggle stupidity when there is so much of it readily available?" -- Alan Dean Foster, GLORY LANE
ags@j.cc.purdue.edu.UUCP (09/29/87)
In article <2619@aw.sei.cmu.edu> firth@bd.sei.cmu.edu.UUCP writes: (An excellent critique of the error messages in f77) I agree that all of your suggestions represent improvements in the error reporting. I anticipated at least one of your points when I suggested identifying the statement as an assignment statement. However, I would like to point out two things: 1. Any experienced FORTRAN programmer should be able to decipher the f77 error messages without difficulty, as has already been demonstrated on the net. 2. The main problem with f77 is not the poor error messages, but the poor performance. >As a last point: compilers that do all the above exist, and exist in >profusion. After using some of them, you might come to hold my view, >that Unix is cursed with too much amateur software. (Or you might not; >tastes vary) I have used many FORTRAN compilers, but f77 is not one of them (except for one or two trivial test runs when I was curious to find out what it would do). I use Unix (which I think is an excellent operating system for most of my work), and I use FORTRAN, but I do not use FORTRAN on Unix. -- Dave Seaman ags@j.cc.purdue.edu