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}