Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site hadron.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!cmcl2!seismo!rlgvax!hadron!jsdy
From: jsdy@hadron.UUCP (Joseph S. D. Yao)
Newsgroups: net.lang.c
Subject: Re: "C" wish list/semicolons
Message-ID: <59@hadron.UUCP>
Date: Thu, 7-Nov-85 00:22:39 EST
Article-I.D.: hadron.59
Posted: Thu Nov  7 00:22:39 1985
Date-Received: Sun, 10-Nov-85 08:25:41 EST
References: <335@graffiti.UUCP> <895@rlvd.UUCP> <742@mmintl.UUCP> <6107@utzoo.UUCP> <142@ucbjade.BERKELEY.EDU>
Reply-To: jsdy@hadron.UUCP (Joseph S. D. Yao)
Organization: Hadron, Inc., Fairfax, VA
Lines: 29
Keywords: language design C semicolons argh
Summary: This "example" is broken.

In article <142@ucbjade.BERKELEY.EDU> mwm@ucbopal.UUCP (Mike (I'll be mellow when I'm dead) Meyer) writes:
>Taking that into account, the best thing for semicolons is:
>	Let them separate two staments on the same line. Let line breaks
>	terminate statements if it makes sense to do so.
>For example, a block could look like:
>	{
	...
>	f = x + 7	/* Does this end? */
>		* y	/* Uh, no... */
>	}

Conveniently ignoring or forgetting that this is legal as two
separate statements, also!  Yes, the second is a no-op -- but
it parses correctly.  Here's another:
	{
		x = func2
			(bool)
		y = TRUE
	}
Now, in 2 seconds, tell me whether I forgot to typedef char bool
and func2 is an int, or forgot to declare bool and func2 is an
int ().

Not so easy, eh?  The point is that between BCPL and C we gained
a lot of richness & complexity, which makes it necessary to use
a slightly more complicated grammar to express all this neat stuff.
-- 

	Joe Yao		hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}