🚀 go-pugleaf

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.