cottrell@nbs-vms.ARPA (08/22/85)
/* > > > ???: > > > if (sv > score); <----- note extraneous semi-colon > > > score = sv; > > Doug Gwyn: > > This sort of thing makes me think that a few extra keywords > > are called for programming languages like this. E.g. > > if <bool_expr> then <stmt> fi > > while <bool_expr> do <stmt> od > > Something to keep in mind when you design an Algol-like language. > > ICK ICK ICK! I hate languages that do that. Ever considered using "cb" as a > debugging tool? I have an MS-DOS version if anyone wants it... > -- > Peter da Silva (the mad Australian werewolf) > UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter > MCI: PDASILVA; CIS: 70216,1076 Dear Peter, Welcome to the `Let's Disagree with Doug' club! Unfortunately, I am forced to agree with him here. CB (& INDENT) is A Good Thing, but since I am such a wonderful coder (:-) I rarely use them. What they really are useful for is importing code written by cretins. Also, I probably disagree slightly with the output of those formatters. What would you do, compare the output of `cb' with the original? Takes lots of time & can be visually overlooked. Anyway, to get back to the point, you come to realize that in if <exp> then <stmt> else <stmt> fi the parens around <exp> are unneccesary. And the `fi' makes sure that all the elses nest with the correct `if'. The Bourne shell has the following definitions, (which many peole dislike, but I think they're OK) #define IF if( #define THEN ){ #define ELSE }else{ #define FI } The point is, you need at least 4 tokens (or a `one-statement' model) to delimit the three parts of an `if' from each other and the outside. C uses four (not counting semicolons)in the short form (if (e) s1; else s2;) and eight in the long form (if (e) { s1; } else { s2; }). And let's get rid of those semicolons too! A newline should imply one. Two statements on a line would need an explicit one. An escaped newline would continue to the next line. Yeah, I know, write my own language! jim cottrell@nbs */ ------
ee161bep@sdcc3.UUCP (Paul Van de Graaf) (08/24/85)
In article <872@brl-tgr.ARPA> cottrell@nbs-vms.ARPA writes: >The point is, you need at least 4 tokens (or a `one-statement' model) >to delimit the three parts of an `if' from each other and the outside. >C uses four (not counting semicolons)in the short form >(if (e) s1; else s2;) and eight in the long form >(if (e) { s1; } else { s2; }). And let's get rid of those semicolons >too! A newline should imply one. Two statements on a line would need >an explicit one. An escaped newline would continue to the next line. >Yeah, I know, write my own language! > > jim cottrell@nbs Couldn't agree with Jim more! Especially on the no semi-colon point. I use Action! (a C/Pascal/Basic derivative) on my Atari, and it has this feature. If Action! had all of C's operators, had more reasonable data types (better struct/unions etc.), AND supported recursion, I'd never look back. Action also has the if <> then <> fi style bracketing which I suppose was inspired by the Bourne shell. I personally don't like the case .. esac stuff in the Bourne shell, but I can't understand why C programmers are so concerned about typing 2 to 5 letter keywords instead of (, ), {, and }. I don't type special characters very well, and I think it's because of having to hit that <shift> key. The QWERTY system is at its best when typing alphas; anything else slows you down, especially when you have to look for the "weird" keys that various brain-damaged manufacturers put in all kinds of crazy positions. I'm ready for something beyond C, and I don't mean C++ or Ada. If no one obliges all just have to do as Jim says and write my own. Paul van de Graaf sdcsvax!sdcc3!ee161bep U. C. San Diego
alexis@reed.UUCP (Alexis Dimitriadis) (08/25/85)
> > > > if (sv > score); <----- note extraneous semi-colon > > > > score = sv; > > ICK ICK ICK! I hate languages that do that. Ever considered using "cb" as a > > debugging tool? I have an MS-DOS version if anyone wants it... > [...] What > would you do, compare the output of `cb' with the original? Takes > lots of time & can be visually overlooked. Here is an idea I've had on the back burner for while: How about a program that checks the formatting of the source code for consistency? - Take a C beautifier. - Modify the lexical analyzer so it passes the amount of indentation preceding the line each input statement is on. - Now for each statement, check the _relative_ indentation. A normal statement should be indented exactly as far as the previous statement; the subordinate part of an "if" or a loop should be further indented, or be on the same line; lines that contain continuation of an expression can start anywhere, and do not affect the expected indent; etc. - If the input disagrees, give a diagnostic. This should catch things like if (tv.set == junk); turn(off); or even while (cat == away) mice(dance); cheese--; since the "while" should be aligned with the "cheese". Of course, it would be powerless with if (procter & gamble); chips++; unless you put in a rule about multiple equal-level statements on the same line, which would create problems with macro expansion, etc. Now I haven't started work on this yet, (first I finish my thesis), but it seems it could be made to work consistently, and without a lot of false alarms. However, a friend who may know better disagrees. Are there really impossible obstacles to the task? I know the lexical analyzer would have to keep track of the offset, and probably line number, of every token, but that's no big deal. Could it cope with the thousands of indenting styles? I think the test is general anough to cope with anything. Since there are so many places braces can be, they could be just ingored. Is it a pipe dream? Has it been done before? (If it has, it must be a well kept secret!). What should I watch out for? Whose code would it gag on? If you have the answers to any of this, (or even some good questions), I would appreciate hearing from you. Finally, I apologize for the length of this, and please! none of the above condones of condemns any particular style of indenting, the subject has been trashed to death anyway. I have kept the results of the indenting style survey, I will mail them to anyone interested. Thanks for your attention, Alexis Dimitriadis PS. I have lost the name of the person who conducted the survey. If you still have the "other style" answers, could you send me a list? -- _______________________________________________ As soon as I get a full time job, the opinions expressed above will attach themselves to my employer, who will never be rid of them again. alexis @ reed ...teneron! \ ...seismo!ihnp4! - tektronix! - reed.UUCP ...decvax! /
arnold@ucsfcgl.UUCP (Ken Arnold%CGL) (08/28/85)
In article <2968@sdcc3.UUCP> ee161bep@sdcc3.UUCP (Paul Van de Graaf) writes: >Action also has the if <> then <> fi style bracketing which I suppose was >inspired by the Bourne shell. I personally don't like the case .. esac stuff >in the Bourne shell, but I can't understand why C programmers are so concerned >about typing 2 to 5 letter keywords instead of (, ), {, and }. I don't type >special characters very well, and I think it's because of having to hit that ><shift> key. To me it is not a question of typing, but a question of bandwidth. Keywords look a lot like variables unless read, whereas symbols don't look like variables at all. The extreme examples are something like add a to b and assign to c vs. c = a + b where the second is clearly more legible. This can be taken to extremes, of course, but I still find that it is easier to scan a language which uses a reasonably rich token set instead of a lot of keywords. Once you learn such a set of symbols, it seems easier to read quickly, probably because the bandwitdh of communication is higher, and operators are quickly visible as operators, as distinct from programmer-defined tokens. How easy a language is to type seems relatively unimportant compared to other factors, including legibility. APL is reasonably easy to *type*... Ken Arnold
peter@graffiti.UUCP (Peter da Silva) (08/30/85)
> > > > > if (sv > score); <----- note extraneous semi-colon > > > > > score = sv; > > > ICK ICK ICK! I hate languages that do that. Ever considered using "cb" as a > > > debugging tool? I have an MS-DOS version if anyone wants it... > > [...] What > > would you do, compare the output of `cb' with the original? Takes > > lots of time & can be visually overlooked. Yes. Since I write cb-like code in the first place it's very easy to just diff it... any lines diff catches are either long function calls or errors of this type.