Re: Semantic error recovery

Our esteemed moderator writes:
>[How many people find it useful for a compiler to chug through and try to
>parse and diagnose an entire file in the presence of errors?


In article 93-11-120 dww@inf.fu-berlin.de writes:
>I don't like compilers that give up right away, I'd prefer to be able to
>set a threshhold ("Give me 20 errors, max!"), especially if it's a
>compiler that takes a long time to get off the ground. However, my
>students constantly fix *just* the first error and recompile[...]


I find it depends on the way the compiler reports the errors. When you
use Unix command line based compilers, you typically get a line by line
listing of errors. Generally it makes sense to fix the error at the head
of the list first (generally it is the most accurately reported error
since the parser may not resynch the input stream correctly). So they fix
up the first error, and if they're lucky the second one, but by then the
line numbers have changed and it becomes hard to realise which error is
related to which line. So they recompile to adjust the line numbers!


IDE type environments (integrated compiler/editor) are superior because
they keep track of the original lines, even if lines are inserted or
deleted in front of them. I find with this sort of environment I'll be
able to correct all the errors in a single run (up to the 20 or whatever
limit).


Unix does have some utilities that emulate this by taking the error
messages and inserting them as comments into the source file. Of course,
many students are probably too busy to stuff around and learn how to use
these sort of things; they'd much rather get their assignments out.


cheers
bj
--

Return to the comp.compilers page.
Search the comp.compilers archives again.