mwm@ucbopal.BERKELEY.EDU (Mike (I'll be mellow when I'm dead) Meyer) (11/06/85)
Humbug! People arguing about whether semicolons should separate or terminate
statements are in the same class as people arguing whether 8080's or 6502's
are the microprocessor of choice. There's a commonly used better way than
either alternative.
The thing to remember is that PEOPLE are the most important readers of a
program. If they can't read and understand it, they can't maintain it.
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:
{
x = 23; y = 40
z = x + y
printf("Messy Format", x, y, z,
f) /* Statement didn't end, as it wouldn't parse */
f = x + 7 /* Does this end? */
* y /* Uh, no... */
}
No mess, no sweat when adding statements. Fewer kestrokes, and it's easier
to read than either other version.
Since modern languages like CLU, Icon and BCPL (BCPL! Waitaminute!) allow
this, I think it belongs on any C wish list. Note that it wouldn't break
existing programs, either (well, I *hope* it wouldn't, but C expression are
such a mess that it might. Moving one token one line should fix things in all
cases).
Note: I haven't considered all the problems implicit in doing this in C. I'd
rather work on modern languages. But this started as a "wish list."
Second Note: The example was chosen to illustrate the features, not for
readability. If you think putting semicolens at the end of each statement
will improve the readability of the example, you have my sympathy.
<mike
P.S. No, I don't know why this disappeared between BCPL and C (at which
step?). Anyone care to explain?ark@alice.UucP (Andrew Koenig) (11/06/85)
> 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: > { > x = 23; y = 40 > z = x + y > printf("Messy Format", x, y, z, > f) /* Statement didn't end, as it wouldn't parse */ > f = x + 7 /* Does this end? */ > * y /* Uh, no... */ > } Ummm... the assignment to f is problematic. Let's change it a bit: f = x + 7 *p++ Now, is this one statement or two? I strongly suggest that if you want to have a syntactic rule for continuing a statement, you make it a lexical rule instead, as in EFL. Thus, if the last token on a line is {insert list here}, the statement is continued. The list would be exactly those tokens that cannot ever end a statement, such as ( = + - * / and so on.
savage@ssc-vax.UUCP (Lowell Savage) (11/06/85)
> > The thing to remember is that PEOPLE are the most important readers of a > program. If they can't read and understand it, they can't maintain it. > 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: > > { > x = 23; y = 40 > z = x + y > printf("Messy Format", x, y, z, > f) /* Statement didn't end, as it wouldn't parse */ > f = x + 7 /* Does this end? */ > * y /* Uh, no... */ > } That's fine, but what about this: { x = 23 + 7 /* Does this end? */ * y = 40 /* Or do we multiply by y which is contains the value 40...or is this simply an error?? */ } What semicolons do is remove ambiguity (even if it is only partial). If semicolons (or other statement separator or terminator) is explicitly required by the syntax of the language, then the reader doesn't have to go through "is y a pointer or is it an integer" before he can determine where how many statements he has. Also, can you imagine how hard it would be to right a compiler that would do all of that kind of semantic processing to find stuff like that? And error recovery? > No mess, no sweat when adding statements. Fewer kestrokes, and it's easier > to read than either other version. Sorry, I disagree. > Since modern languages like CLU, Icon and BCPL (BCPL! Waitaminute!) allow > this, I think it belongs on any C wish list. You mean that they have *NO* statement terminator or separator??!! (Sorry if I'm exposing my ignorance on these languages.) If so, then they must have some other way of resolving ambiguities like the example above. These are my own personal biases. Anyone that wants to share them will have to fill out a 100-page non-disclosure agreement in octuplicate (without carbons), send all copies with 2 dollars for processing to outer Tanzania, wait two years, and chant "Mousy Dung was a bad guy." five hundred times. All questions on this matter will be refered to the Bureau of non-violent violence (BNVV)...or was that the Association for the Promulgation of Persons Against Associations (APPAA)? There's more than one way to be savage Lowell Savage
jsdy@hadron.UUCP (Joseph S. D. Yao) (11/07/85)
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}
david@ukma.UUCP (David Herron, NPR Lover) (11/07/85)
In article <142@ucbjade.BERKELEY.EDU> mwm@ucbopal.UUCP (Mike (I'll be mellow when I'm dead) Meyer) writes: > >Humbug! People arguing about whether semicolons should separate or terminate >statements are in the same class as people arguing whether 8080's or 6502's >are the microprocessor of choice. There's a commonly used better way than >either alternative. > >The thing to remember is that PEOPLE are the most important readers of a >program. If they can't read and understand it, they can't maintain it. >Taking that into account, the best thing for semicolons is: I agree. But I have a solution which will solve *everything* (:-)). >For example, a block could look like: > > { > x = 23; y = 40 > z = x + y > printf("Messy Format", x, y, z, > f) /* Statement didn't end, as it wouldn't parse */ > f = x + 7 /* Does this end? */ > * y /* Uh, no... */ > } > >No mess, no sweat when adding statements. Fewer kestrokes, and it's easier >to read than either other version. Welllll.... "*y" is a legal C statement all by itself. All this stuff with blocks (and whether to use begin...end or {..}) is silliness. Why not be totally visual about it? When you want a block of stuff, simply draw a box around it. For goto statements, draw a line from the box to wherever you want to go. Sigh. It doesn't solve the seperator problem (unless you want to have one box per statement). -- David Herron, cbosgd!ukma!david, david@UKMA.BITNET. English is a second language to me -- Baby talk was my first language.
pcf@drux3.UUCP (FryPC) (11/07/85)
> Let (semicolons) them separate two staments on the same line. Let line breaks > terminate statements if it makes sense to do so. > ... > Since modern languages like CLU, Icon and BCPL (BCPL! Waitaminute!) allow > this, I think it belongs on any C wish list. > ... > P.S. No, I don't know why this disappeared between BCPL and C (at which > step?). Anyone care to explain? The problem is that C overloads operators, in particular "*"; as "*" can leagally start (indirection) or legally continue (multiplication) a statement. Combined with the fact that assignments have a value, the following fragment could be parsed in (at least) two ways. x = a * b /* x = a * b * (c = 1); */ *c = 1 /* or x = a * b; *c = 1; */ A solution is to make "*" (indirection) a postfix operator. This would also make declarators using pointers easier, as all modifiers would be postfix and parentheses would not be required for grouping. You could read off everything left to right. Example: A function returning a pointer to a function returning an integer: int (*func(args))() becomes int func(args)*() And that is one thing on my 'I wish they had done it this way' list. Peter Fry drux3!pcf "Oh Bullshot, you are wonderful." "No, not wonderful, just British."
levy@ttrdc.UUCP (Daniel R. Levy) (11/08/85)
In article <4528@alice.UUCP>, ark@alice.UucP (Andrew Koenig) writes: >Ummm... the assignment to f is problematic. Let's change it a bit: > f = x + 7 > *p++ >Now, is this one statement or two? I strongly suggest that if >you want to have a syntactic rule for continuing a statement, >you make it a lexical rule instead, as in EFL. Thus, if the >last token on a line is {insert list here}, the statement is >continued. The list would be exactly those tokens that cannot >ever end a statement, such as ( = + - * / and so on. What about something++ more(code) -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!ihnp4!ttrdc!levy
friesen@psivax.UUCP (Stanley Friesen) (11/12/85)
In article <564@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: >In article <4528@alice.UUCP>, ark@alice.UucP (Andrew Koenig) writes: >> >> Thus, if the >>last token on a line is {insert list here}, the statement is >>continued. The list would be exactly those tokens that cannot >>ever end a statement, such as ( = + - * / and so on. > >What about > > something++ > more(code) > This is not a good counter example, since most(or all) lexical analyzers for 'C' treat '+' and '++' as entirely different tokens. Thus the token '++' would *not* be in the "continue" list, while the token '+' would. -- Sarima (Stanley Friesen) UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen ARPA: ttidca!psivax!friesen@rand-unix.arpa
seifert@hammer.UUCP (Snoopy) (11/14/85)
In article <2364@ukma.UUCP> david@ukma.UUCP (David Herron, NPR Lover) writes: >All this stuff with blocks (and whether to use begin...end or {..}) >is silliness. > >Why not be totally visual about it? When you want a block of stuff, >simply draw a box around it. For goto statements, draw a line from the >box to wherever you want to go. > >Sigh. It doesn't solve the seperator problem (unless you want to >have one box per statement). Sounds like you want to program in "flowchart". Snoopy (ECS Ronin #901) tektronix!tekecs!doghouse.TEK!snoopy