To my way of thinking, the least mind-bending option is to say that escaping has unequivocally higher precedence than any syntax that uses newlines: either you see the escape token at the end of a line, or the newline isn't escaped.
I think this is precisely where pragmatism and conceptual simplicity diverge: the option you describe leads directly to the ASCII art trap, which it seems to me is a severe violation of the Principle of Least Astonishment (especially in C/C++'s strict implementation where invisible trailing whitespace can change the meaning) and imparts a fair amount of mindbendingness to my way of thinking.
your point that the syntax of preprocessor directives in C/C++ is an obvious misfeature in the first place. (If they could be freely interpolated, life would be much better in many ways [...])
That's a considerably broader point than the one I'd intended to make, but I'll cheerfully subscribe to it regardless. Being able to embed macro definitions anywhere, including in the expansions of other macros, would certainly offer scope for some exciting perversions :-)
Though that makes comment-to-nl itself feel like a mistake in the language
It is odd, now I think about it, that neither of C/C++'s comment syntaxes nests properly. If they were going to throw in a second comment syntax, they could have had it fix the bug in the first one!
you don't make explicit what you want this to do: [...] I'm guessing you want it to treat ten.o and eleven.o as being on the same line?
Yes, that was my intention. (I thought I had made that explicit, though perhaps I left an unintended loophole in the wording. The line containing ten.o has a line-splicing backslash by rule 1, and therefore rule 3 applies to the line following it.)
Rule 3 is a curveball, I agree, but then I was approaching the entire problem from a use-cases perspective to see what would happen, and since the conceptually clean approaches in C/C++ and shell both turn out to lead to weird use cases, it didn't surprise me that my use-case-focused reanalysis led to weird concepts :-)
a far neater solution is to set aside a dedicated character, not used for anything else, and say that character to end of line is whitespace
Hmm, yes, that is quite neat; a sort of comment-to-just-after-nl as opposed to (or rather, offered as an alternative to) the more usual comment-to-just-before-nl.
no subject
I think this is precisely where pragmatism and conceptual simplicity diverge: the option you describe leads directly to the ASCII art trap, which it seems to me is a severe violation of the Principle of Least Astonishment (especially in C/C++'s strict implementation where invisible trailing whitespace can change the meaning) and imparts a fair amount of mindbendingness to my way of thinking.
your point that the syntax of preprocessor directives in C/C++ is an obvious misfeature in the first place. (If they could be freely interpolated, life would be much better in many ways [...])
That's a considerably broader point than the one I'd intended to make, but I'll cheerfully subscribe to it regardless. Being able to embed macro definitions anywhere, including in the expansions of other macros, would certainly offer scope for some exciting perversions :-)
Though that makes comment-to-nl itself feel like a mistake in the language
It is odd, now I think about it, that neither of C/C++'s comment syntaxes nests properly. If they were going to throw in a second comment syntax, they could have had it fix the bug in the first one!
you don't make explicit what you want this to do: [...] I'm guessing you want it to treat ten.o and eleven.o as being on the same line?
Yes, that was my intention. (I thought I had made that explicit, though perhaps I left an unintended loophole in the wording. The line containing ten.o has a line-splicing backslash by rule 1, and therefore rule 3 applies to the line following it.)
Rule 3 is a curveball, I agree, but then I was approaching the entire problem from a use-cases perspective to see what would happen, and since the conceptually clean approaches in C/C++ and shell both turn out to lead to weird use cases, it didn't surprise me that my use-case-focused reanalysis led to weird concepts :-)
a far neater solution is to set aside a dedicated character, not used for anything else, and say that character to end of line is whitespace
Hmm, yes, that is quite neat; a sort of comment-to-just-after-nl as opposed to (or rather, offered as an alternative to) the more usual comment-to-just-before-nl.