🚀 go-pugleaf

> There's a reason for the semicolon that seems to be missed here. 
[deleted]
> The semicolons are there so that if the compiler hits an error, and
> gets really confused, it may easily find the end of the statement and recover
> to continue parsing the program.

If your language has blocks, just recover to the end of the block
rather than the end of the statement.  If you don't have blocks, skip
to the end of what you do have (the file if necessary).

I don't particularly agree with the argument that you should minimise
the amount of code skipped.  If you have an error, then it should be
reported and after that all bets are off.

In order to continue parsing the compiler writer has to insert damage
control code to try and reduce the effect of an error.  As a user,
there is no simple way of knowing that the writer was successful and
that any subsequent errors aren't infact caused by the original error.
i.e. if you believe subsequent errors, you can waste time looking for
errors that don't acutally exist.  I grant that you can apply
intelligent filtering to this and make guesses as to what may or may
not be affected by previous errors, but they are just that, guesses.

If you are submitting batch jobs for compilation on some system, then
I can see a possible reason for trying to detect as many errors as
possible, but what percentage of people still write code like this?
I would have thought that most code is now developed in PCs,
workstations and alike, where the edit-compile-run cycle is quite
small.

Stephen J. Bevan		bevan@cs.man.ac.uk