Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!mcnc!xanth!kent
From: kent@xanth.UUCP (Kent Paul Dolan)
Newsgroups: comp.lang.fortran
Subject: Re: "Interesting" error interpretation by f77.
Message-ID: <2483@xanth.UUCP>
Date: Fri, 18-Sep-87 06:38:38 EDT
Article-I.D.: xanth.2483
Posted: Fri Sep 18 06:38:38 1987
Date-Received: Sun, 20-Sep-87 05:46:22 EDT
References: <5117@jade.BERKELEY.EDU>
Reply-To: kent@xanth.UUCP (Kent Paul Dolan)
Organization: Old Dominion University, Norfolk Va.
Lines: 112
Keywords: FORTRAN parsing, error interpretation.

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