Here's a thing I was pondering the other day about lexing.
Suppose you have a language containing two moderately common lexical features: a comment mechanism in which comments are newline-terminated (C++/C99 style //, shell #), and a line-splicing mechanism in which a backslash at the end of a line causes the next line to be glued on to it as if
(
Read more... )
Comments 3
The article in question is perhaps more locally exemplified by:
#include
#define FOO() \
printf("A\n"); \
// printf("B\n"); \
printf("C\n"); \
printf("D\n")
int main(int argc, char *argv[])
{
printf("1\n");
// foo \
printf("2\n");
printf("3\n");
printf("\n");
FOO();
return 0;
}
Which does two thing which one might not expect, one more so than the other.
I think your rules fix both of them, but do enable constructs where the start of the line splice is divorced by many comment lines from what it is spliced to, which might not be ideal. (If that makes a semantic difference, then perhaps one could consider that another argument against python...) Perhaps a requirement that all ignored comment line *must* also be splicing lines? Dunno.
Reply
printf("complicated format string",
arg1,
arg2, // \
arg3, // } comment about these three
arg4, // /
arg5);and got mysterious compiler warnings about the format string mismatching the parameters, which turned out to be because arg3 had been dropped on the floor. (Mystery eventually solved by using a later version of gcc, which helpfully gave a warning about the line-continued comment.)
Reply
http://thedailywtf.com/Articles/A-Bad-Leg.aspx
Which made a complete hash of telling the story, but is possible to figure out what was actually going on (and it fails just the same in gcc contrary to their telling), and surprised quite a few people reading it.
Reply
Leave a comment