Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site Cascade.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!decwrl!Glacier!Cascade!asente
From: asente@Cascade.ARPA
Newsgroups: net.lang.mod2
Subject: Re: Aren't people fed up with semicolons yet?
Message-ID: <861@Cascade.ARPA>
Date: Wed, 17-Apr-85 18:09:38 EST
Article-I.D.: Cascade.861
Posted: Wed Apr 17 18:09:38 1985
Date-Received: Sat, 20-Apr-85 04:24:19 EST
References: <4003@mit-eddie.UUCP> <125@bocklin.UUCP>
Organization: Stanford University CIS Apple Orchard
Lines: 49

...!bocklin!gary says:

> In an early version of Icon (I have not checked the problem recently),
> the code segment
> 
> 	a:= ( ... very long expression  ... )
> 	    + (another long expression) ;
> 
> was treated as *two* statements. (Expressions really.  Icon, like C,
> is an expression language.)  ``a'' was assigned the value of the first
> expression and the second value was thrown away.
.
.
.
> The correct ``fix'' was to write
> 
> 	a:= ( ... very long expression  ... ) +
> 	    (another long expression) ;
> 
> The compiler was smart enough to know that ``optional'' semicolons
> don't follow operators.  The real problem was that I couldn't get a
> good explanation of when ``optional'' semicolons would be inserted.

This seems to stem from a misunderstanding of the meaning of the
semicolon 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 +
		c
rather than
	a := b
		+ c	.
Or, for another example, you have to say
	if (condition) 
	then statement
rather than
	if (condition) then
		statement
which is a null statement after the condition.

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.

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