Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!iuvax!rutgers!rochester!pt.cs.cmu.edu!sei!sei.cmu.edu!firth
From: firth@sei.cmu.edu (Robert Firth)
Newsgroups: comp.lang.misc
Subject: Re: Algol-style semicolons
Keywords: semicolons, statements, end
Message-ID: <8008@aw.sei.cmu.edu>
Date: 15 Dec 88 13:30:25 GMT
References: <1126@etive.ed.ac.uk> <208100002@s.cs.uiuc.edu> <868@mcrware.UUCP>
Sender: netnews@sei.cmu.edu
Reply-To: firth@bd.sei.cmu.edu (Robert Firth)
Organization: Carnegie-Mellon University, SEI, Pgh, Pa
Lines: 48

In article <868@mcrware.UUCP> jejones@mcrware.UUCP (James Jones) writes:
>I never could understand what the difficulty is with Algol-style semicolons..

I've used languages with various kinds of semicolon conventions, and must
admit that I like the Algol-68 way least.

The best, in my opinion, is to have the semicolon optional: a newline
will terminate the statement if possible.  So you can write

	x := x+1
	y := y+1

and it works, but

	x := a0+a1+a2+
	     a3+a4+a5

also works.  One hardly ever gets this wrong.

If the semicolon is mandatory, I prefer it to be a terminator, precisely
because I then don't have to edit two lines to insert or remove one
statement.

Finally, if the semicolon is a separator, the language should be kind
enough to allow an extra semicolon before a syntactic bracket, either
by having a "null statement" or by some other fudge.

Much the nastiest part, though, is that the compilers I have used have
been very obtuse about recovering from the simplest errors.  The Algol-68
compiler had a great repertoire of error messages, from

	OBJECT OF MODE PROC()VOID CANNOT BE WEAKLY COERCED TO REF CHAR

to some really frightening ones; what most of them meant was either
"missing semicolon on previous line" or "extra semicolon on previous
line".  And I remember the Algol-60 compiler that could not recover
from

	IF c THEN s; ELSE s;

which is a single-token correction.  The real booby price, though, goes
to the C compiler where omitting a semicolon before a right brace:

	if (...) { s1; s2 }

causes an indefinite number of bogus consequential errors, until either
the compiler gives up "too many errors - goodbye" or your program text
ends.  Since the repair here is perhaps the simplest possible, this
compiler feature represents incompetence of a rare order.