vlcek@mit-caf.MIT.EDU (Jim Vlcek) (05/06/89)
In article <1273@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
(Recommends requiring an escape character before newlines in multiline
statements, noting that this is already the case for macros)
Grrrrr..... I've programmed in a lot of languages, and I've always
found that those which required escaping newlines in multiline
statements are the most royal pain in the ass to work with.
You see, we have to _read_ the source code we write, and having extra
characters in the source to escape newlines adds clutter which impedes
one's recognition of the source text. Consider: in normal printed
text, a carriage return is simple whitespace. Why should it be
different in source code?
I don't think that anyone would like to have to read their morning\
newspaper, or all of the articles in comp.lang.c, with everyone line\
break escaped, because someone wanted to eliminate the ``superfluous''\
period
And imagine this
Everytime one starts a new statement, one must insert a carriage\
return
No matter how short it is
No matter how annoying that gets
Get the point?
In fact, I myself would lean the other direction and prefer that
macros not follow the strict ``to the next newline'' rule, but rather
have a more explicit means of terminating the definition body. I
don't like the notion that source which fits into a macro might not be
directly insertable into regular source code (due to the presence of
backslashes to escape newlines).
Jim Vlcek (vlcek@caf.mit.edu uunet!mit-eddie!mit-caf!vlcek)geoff@cs.warwick.ac.uk (Geoff Rimmer) (05/08/89)
In article <2296@mit-caf.MIT.EDU> vlcek@mit-caf.MIT.EDU (Jim Vlcek) writes: > In fact, I myself would lean the other direction and prefer that > macros not follow the strict ``to the next newline'' rule, but rather > have a more explicit means of terminating the definition body. I agree that it can be *very* annoying having to backquote all the newlines in macros (take a look at "putc" in stdio.h !) But how else could cpp be designed so it knows when to stop? By matching the parentheses/ brackets & braces? Problem is some (admittedly braindead) people write macros like #define ERROR fprintf(stderr, and then use ERROR "This is an error\n"); Perhaps you could force the macro definition to appear within braces, for example the above would be #define ERROR {fprintf(stderr,} and when the text substitution is made, the braces will not be inserted. However, this could make some macros even more difficult to read than having \'s down the RHS. For example, I often use the macro, V--- Ha! Nuts to all you haters of case-sensitivity! :-) #define Malloc(x) ({char *tempptr=malloc(x); \ if (!tempptr) perror_("malloc failed");tempptr;}) (BTW this is only when I'm using gcc - so no flames!) If I had to put the RHS in another set of braces, I'd have 3 types of brackets - just to get rid of the backslash! I guess having to backslash all the newlines is the "least bad" solution to the problem of readability, although I'll agree that it can be a pain in the <enter any part of the anatomy>. > Jim Vlcek (vlcek@caf.mit.edu uunet!mit-eddie!mit-caf!vlcek) Geoff /---------------------------------------------------------------\ | GEOFF RIMMER - Friend of fax booths | | email : geoff@uk.ac.warwick.cs | | address : Computer Science Dept, Warwick University, | | Coventry, England. | | PHONE : +44 203 692320 (10 lines) | | FAX : +44 865 726753 | \---------------------------------------------------------------/
jlg@lanl.gov (Jim Giles) (05/09/89)
From article <2296@mit-caf.MIT.EDU>, by vlcek@mit-caf.MIT.EDU (Jim Vlcek): > You see, we have to _read_ the source code we write, and having extra > characters in the source to escape newlines adds clutter which impedes > one's recognition of the source text. Consider: in normal printed > text, a carriage return is simple whitespace. Why should it be > different in source code? It should be different in source code because programming is a _different_ process than generating normal printed text (or do you also start every program statement with a capital letter, etc?). I'm glad _I_ don't have to read your source code. I _REALLY_HATE_ it when somebody squashes all their source together. > And imagine this > Everytime one starts a new statement, one must insert a carriage\ > return > No matter how short it is > No matter how annoying that gets > Get the point? And imagine this: somebody writing code the way Jim Vlcek is recommending- printd(n) /* print n in decimal*/ int n; if (n<0) {putchar('-');n= -n;} i=0; do {s[i++]=n%10+'0'; /* get next char */ } while ((n/=10) >0); /* discard it */ while (--i >= 0) putchar(s[i]);} printd(n) /* print n in decimal (recursive) */ int n; {int i; if (n<0) {putchar ('-'); n= -n;} if ((i=n/10) !=0) printd(i); putchar(n%10+'0');} Get the point? _NOBODY_ writes _PROGRAMS_ this way. _EVERYBODY_ uses the end-of-line as _MORE_ than _just_ whitespace. In fact, almost everyone begins each program statement on a separate line. The design criterion of relevance here is that the most common usage should have the simplest syntax - that is, let the end-of-line be a statement terminator (keep semicolon also, this allows multiple statements per line if desired). The _less_ common usage (by a _long_ shot) is continuation of statements across lines - it is _this_ case that should have the extra syntax of an escaped carriage return. The extra syntax is _not_ clutter, it serves to point out explicitly the unusual occurrance of a continued line. (Program above was both examples from page 85 of K&R.)
badri@valhalla.ee.rochester.edu (Badri Lokanathan) (05/09/89)
>In article <2296@mit-caf.MIT.EDU> vlcek@mit-caf.MIT.EDU (Jim Vlcek) writes: >> In fact, I myself would lean the other direction and prefer that >> macros not follow the strict ``to the next newline'' rule, but rather >> have a more explicit means of terminating the definition body. In article <1843@ubu.warwick.UUCP> geoff@cs.warwick.ac.uk (Geoff Rimmer) writes: >I agree that it can be *very* annoying having to backquote all the >newlines in macros (take a look at "putc" in stdio.h !) But how else >could cpp be designed so it knows when to stop? By matching the >parentheses/ brackets & braces? One could have a default set of delimiters that can be modified on the fly (as in sed pattern matching, for instance) Say the default is ^ #define Foo ^your macro^ But if your macro contains ^, then modify by #define Foo @your macro@ cpp can easily be designed to recognize the first non-white character as a delimiter ... -- "I care about my fellow man {) badri@ee.rochester.edu Being taken for a ride, //\\ {ames,cmcl2,columbia,cornell, I care that things start changing ///\\\ garp,harvard,ll-xn,rutgers}! But there's no one on my side."-UB40 _||_ rochester!ur-valhalla!badri
usenet@TSfR.UUCP (usenet) (05/09/89)
In article <13292@lanl.gov> jlg@lanl.gov (Jim Giles) writes: > In fact, almost everyone >begins each program statement on a separate line. When rotating an argument list, I use the form ++argv; --argc; /* some descriptive comment */ This is a good way of showing that those two statements should be considered as one thing. splitting them over two lines makes them blend in with the rest of the code, so I need to stuff extra comments and whitespace around them to make them stand out. And, of course, when they are split onto different lines, they become vulnerable to continental drift. >The _less_ common usage (by a _long_ shot) is continuation of statements ^^^^^^^^^^^^^^^^ Not in the code I work with... >across lines - it is _this_ case that should have the extra syntax of >an escaped carriage return. Which, if you miss it, can lead to all sorts of hard-to-find problems if you're using a language which is as rich as C. For example: pointer_expression_one = (complex_pointer_expression_2) -(complex_scalar_expression) Leave the escape off the first line and you've got two valid statements. With (for example) C, leave the semicolin off the second line and you've got error messages. The problem with escaping newlines on continuations is that it's easier to forget what you're doing when you have to do extra work in rare special cases. If you have to tell the compiler that you are ending _every_ statement, you're less likely to forget it where it's important. (How many times to C programmers forget the semicolins on statements as opposed to the number of times pascal programmers forget to _not_ put semicolins on the `special' statement blocks...?) -david parsons -orc@pell.uucp
peter@ficc.uu.net (Peter da Silva) (05/09/89)
In article <1843@ubu.warwick.UUCP>, geoff@cs.warwick.ac.uk (Geoff Rimmer) writes: > In article <2296@mit-caf.MIT.EDU> vlcek@mit-caf.MIT.EDU (Jim Vlcek) writes: > > In fact, I myself would lean the other direction and prefer that > > macros not follow the strict ``to the next newline'' rule, but rather > > have a more explicit means of terminating the definition body. Me too... > I agree that it can be *very* annoying having to backquote all the > newlines in macros (take a look at "putc" in stdio.h !) But how else > could cpp be designed so it knows when to stop? A new construct for multiline macros? #begin Malloc(x) ({char *tempptr=malloc(x); if (!tempptr) perror_("malloc failed");tempptr;}) #end > (BTW this is only when I'm using gcc - so no flames!) I think it's kind of cute, but then I get nostalgic over BCPL. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
npl@kaiser.UUCP (N Landsberg) (05/11/89)
Regarding the original thoughts about not requiring ';' at the end
of a line, consider the following:
/* code fragment begins */
for(p=begin;p->p_next;p=p->p_next) /* DO NOTHING */ ;
{ /* <---- note!!! */
/* declarations */
/* do something */
}
/* end of code fragment */
Without the trailing ';' it is unclear whether the block is to be
executed as part of the loop. While it is possible to make the
loop unambigious by moving the assignment into a statement in the
loop body, my point is that the above is perfectly valid C and
by implying that end-of-line is statement terminator AND then
leaving off the trailing ';' you open up a whole new set of
latent bugs to track down.flee@shire.cs.psu.edu (Felix Lee) (05/11/89)
In article <873@kaiser.UUCP>, npl@kaiser.UUCP (N Landsberg) writes: > for(p=begin;p->p_next;p=p->p_next) /* DO NOTHING */ ; > { [...] } >Without the trailing ';' it is unclear whether the block is to be >executed as part of the loop. Most languages without explicit statement terminators have a "skip" statement and disallow null statements. -- Felix Lee flee@shire.cs.psu.edu *!psuvax1!shire!flee