Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!ukc!mucs!m1!bevan From: bevan@cs.man.ac.uk (Stephen J Bevan) Newsgroups: comp.lang.misc Subject: Re: improve language by dropping ; Message-ID: Date: 19 Feb 91 12:23:16 GMT References: <8507.27b91f9e@jetson.uh.edu> <329@smds.UUCP> <1991Feb18.140346.8896@jarvis.csri.toronto.edu> <943@creatures.cs.vt.edu> Sender: news@cs.man.ac.uk Distribution: comp Organization: Department of Computer Science, University of Manchester Lines: 31 In-reply-to: lavinus@csgrad.cs.vt.edu's message of 19 Feb 91 00:03:51 GMT > 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