Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!rochester!PT!sei!sei.cmu.edu!firth
From: firth@sei.cmu.edu (Robert Firth)
Newsgroups: comp.lang.fortran
Subject: Re: "Interesting" error interpretation by f77.
Message-ID: <2619@aw.sei.cmu.edu>
Date: Thu, 24-Sep-87 09:02:41 EDT
Article-I.D.: aw.2619
Posted: Thu Sep 24 09:02:41 1987
Date-Received: Sat, 26-Sep-87 16:29:38 EDT
References: <5117@jade.BERKELEY.EDU> <2577@aw.sei.cmu.edu> <5307@j.cc.purdue.edu>
Sender: netnews@sei.cmu.edu
Reply-To: firth@bd.sei.cmu.edu.UUCP (PUT YOUR NAME HERE)
Organization: Carnegie-Mellon University, SEI, Pgh, Pa
Lines: 54
Keywords: FORTRAN parsing, error interpretation.

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)