mike@wuphys.UUCP (Mike Jones) (01/11/85)
Last night I compiled a program on my 2.9BSD system that still had
some typos in it. One particularly interesting error message was
Unknown keyword
Not only does that not the describe the problem (a missing }) but that
doesn't make sense for any problem. I don't know what the standards
committee has to say about error messages, but perhaps we need a line
in the standard prohibiting oxymorons. :-)
Doublethink is getting us ready for: Mike Jones
C++ ihnp4!wuphys!mikeron@brl-tgr.ARPA (Ron Natalie <ron>) (01/15/85)
> Last night I compiled a program on my 2.9BSD system that still had > some typos in it. One particularly interesting error message was > > Unknown keyword > > Not only does that not the describe the problem (a missing }) but that > doesn't make sense for any problem. I don't know what the standards > committee has to say about error messages, but perhaps we need a line > in the standard prohibiting oxymorons. :-) > Some compilers are trying to address the error message problem (like Tartan claims to be attempting if they ever get it working). For an interesting reference in the Journal of Software Theory and Practice there wsa a paper (about three years ago) called "My compiler gives good error messages -- or does it?" They took a Pascal program and introduced a trivial typo-style bug into it to see what message various compilers gave. Their last example was nominated for a special award, it looked like write(tty, foo); ^ Missing Semicolon =Ron
cottrell@nbs-vms.ARPA (01/16/85)
/* how long have you been programming? in case you haven't noticed most compilers spit out cryptic errors when a required delimeter is missing. perhaps languages can be designed that produce more lucid error messages, such as 'unknown keyword "foo", probable missing delimeter ";" or "}"', but C is very sparse. in your case at least the reported line number should be close. */
grunwald@uiucdcsb.UUCP (01/23/85)
what a crock. "most compilers spit out cryptic messages" -- mainly because people are lazy about developing proper parsers. When using a C compiler on a PC/AT w/XENIX, it spits out what it thinks is missing. In a LALR language (e.g. C), you know what the expected followset is supposed to be -- It would be possible to say what you expect to see at this point (although that might be a little too much text). If PCC would use be extended to use the Graham-Rhodes error recovery to try and be a little more graceful about compiling, like the pascal (pc) compiler does, I for one would be a happier grub.
rjk@mgweed.UUCP (Randy King) (01/28/85)
Geez, how can we forget the most favorite of C error messages, which actually came from the assembler pass. It was simply the following: symbol_name: m Which meant a multiple definition. And this kind of stuff only happens when you're just learning. Randy King AT&T-CP@MG ihnp4!mgweed!rjk
julia@ubu.UUCP (Julia Dain) (02/01/85)
>what a crock. "most compilers spit out cryptic messages" -- mainly because >people are lazy about developing proper parsers. > When using a C compiler on a PC/AT w/XENIX, it spits out what it thinks >is missing. In a LALR language (e.g. C), you know what the expected followset >is supposed to be -- It would be possible to say what you expect to see at this >point (although that might be a little too much text). > If PCC would use be extended to use the Graham-Rhodes error recovery >to try and be a little more graceful about compiling, like the pascal (pc) >compiler does, I for one would be a happier grub. The pascal compiler uses Graham-Haley-Joy error recovery techniques, not Graham-Rhodes which is for shift reduce parsers. It does not seem possible to decouple these techniques from pc easily. Eyacc expects a bunch of special error recovery stuff in its input. The pc parser uses lexical and semantic analysis as well as syntactic analysis to guide its choice of error recovery. However I have produced a C compiler with improved error diagnostics based on the state information available in the parser. This is done with a new version of yacc, which can be used by any system currently using yacc, with minimal changes to specifications. The C compiler and yacc are available now; I am still writing up the paper. Julia Dain, Dept Computer Science, Univ of Warwick, Coventry CV47AL, U.K.