[net.lang.mod2] Fed up with semicolons?

macrakis@harvard.ARPA (Stavros Macrakis) (04/19/85)

> [in Icon,] the end of line is the statement terminator, not the
> semicolon.  Continuation is provided by ending the line to be
> continued so that it is not a complete statement; so you have to say
> 	a := b +	rather than	a := b
> 		c				+ c
> Or, for another example, you have to say
> 	if (condition)    rather than	if (condition) then
> 	  then statement			statement
> which is a null statement after the condition.

Having an empty null statement is itself known to be a source of
confusion and error.  This example shows why.

And do I really want to <think> every time I introduce a NL into my
program to format it?

> Several people have stated that semicolon terminators add redundancy to
> a language.  This is false!  There is no redundancy since the
> end-of-line is ignored completely in languages like C.

Any statement terminator (whether EOL or semicolon) is redundant in most
positions in most modern languages.  For instance, "a:=b c:=d" and
"if a then b while c do w" can both be parsed unambiguously (in the
absence of null statements and other pathologies).  Does Icon allow more
than one statement per line?  If so, does it separate them?  If so,
wouldn't it be more consistent to separate all statements the same way?

> The only real purpose for semicolons, as far as I can see, is so that
> lazy compiler writers don't have to work as hard to do error recovery.
>   -paul asente  asente@cascade.ARPA	...decwrl!glacier!cascade!asente

Actually, semicolons and other redundancies (e.g. variable declaration,
keyword syntax, unabbreviable keywords) serve several purposes:

 1. Making programs easier to read. (arguable)
 2. Making it more likely that clerical errors will not transform one
	valid program into another valid but unintended program.
 3. Simplifying the structure of the compiler. (maybe)
 4. Making error recovery more likely to succeed.
 5. Making error recovery easier.

Compiler error recovery is a non-trivial matter and still contains many
open research questions.  `Laziness' may be an issue (vide Unix C
compiler!), but feasability is another.

	-s