[COFF] [TUHS] What would early alternatives to C have been?

Beating a nearly dead horse, I'm shipping this to COFF instead of TUHS to which it responds. Amusing. IT's odd that no one has mentioned the use of spaces for grouping. When the operands of == are simple, I prefer to vary the spacingy spacing. It's less intrusive than extra parentheses and just as clear. if(a==b && c==d) or if( a==b && c==d ) K&R usually flank every infix operator with spaces, unlike classical mathematical usage, where spacing reflects operator precedence. I usually write a*b + c*d, not a * b + c * d, which wantonly flattens the parse tree. Here's an example from K&R, where uniform spacing hampers intelligibility. for (i = 0; s[i] >= '0' && s[i] <= '9'; ++i) n = 10 * n + (s[i] - '0'); The "extra" parens in the second line admirably show the intent of the subtraction. Other groupings are not so well indicated. I would write it like this: for(i=0; s[i]>='0' && s[i]<='9'; ++i) n = 10*n + (s[i]-'0'); (I'll admit that the juxtaposition ]>= is less than perspicuous.) Long identifiers constitute a level of grouping that takes precedence even over multiplication. So I may flank long identifiers with spaces. I suppose then + in a sum of products might deserve double spaces. That's probably a bridge too far, but double spaces after the semicolons in the "for" statement above seem justifiable K&R aren't absolutely rigid about spacing. In the following oddly mixed specimen, the first of three operands in a conjunction is spaced tightly, but the third is not; I guess they feel about != the way I do about long identifiers. i<lim-1 && (c = getchar()) != '\n' && c != EOF The middle conjunct is a challenge. I'd probably squeeze out the spaces. But I might instead try to hold it together with outer parens. Doug