smuj wrote: > Jon Lang wrote: >> smuj wrote: >>> Jon Lang wrote: >>>> Here's a radical notion: use something other than '#' to initiate an >>>> inline comment. >>>> >>> [snippage] >>> >>> Or maybe just don't allow "embedded" comments unless they are actually >>> "embedded", i.e. if a line starts with a # (ignoring leading whitespace) >>> then it's _always_ a line-end comment, no matter what follows the #, e.g. >> >> That has the advantage of preserving a three-character embedded >> comment. It has the disadvantage that you get differing behavior >> depending on where the comment is on the line. As I see it, the whole >> point of this exercise is to get rid of the gotchas, and not just to >> shift them around - thus my ':#' proposal. > > I think whatever the solution is, it must begin with a # -- anything else > will likely create even more gotchas.
When inline comments begin with a '#', the main gotcha arises when you go to comment out a series of lines by prepending a # to each, and one of those lines begins with the proper series of characters to create an inline comment instead. If you add the condition that a line beginning with a '#' is automatically a full-line comment (or, as currently specced, simply complains about the ambiguity), you replace this gotcha with one where someone types in what he intends to be an inline comment, but forgets to indent it. Adding a secondary character after the '#' reduces the likelihood of this happening, but doesn't eliminate it. When inline comments begin with something other than '#', none of the above gotchas exist. Instead, the main gotcha occurs when you go to create an end-of-line comment at the end of a line that ends with whatever the first character of an inline comment is. A programmer who forgets to put whitespace between that character and the '#' will get an inline comment instead. IMHO, this is no different than any other case where the programmer mistakenly allows two different tokens to run together. As well, when programmers add comments to the ends of a series of lines, they generally lead off with whitespace intended to align said comments with each other; so existing habits would not cause difficulties as they currently do for commenting out lines. > Also, we have to realize that no > matter what sequence we choose for embedded comments, there will _always_ be > a chance of a gotcha, so all we can do is minimize the likelihood, as well > as making the gotcha easy to spot, whilst not making embedded comments too > difficult to use for those who like them. My argument is that starting an inline comment with something other than a '#' minimizes the likelihood of gotchas, makes gotchas easy to spot, and doesn't make embedded comments too difficult to use for those who like them. Is there anything that my argument missed? > My current personal favourite would be to keep things as they are with > regards to bracketing, but to introduce a + between the # and the brackets. This reduces the likelihood of ambiguity cropping up between an embedded comment and an end-of-line comment; but it doesn't eliminate the possibility. Reversing the order to '+#' _would_ eliminate any possibility of ambiguity at the start of a line; and the only thing you'd have to watch out for would be someone deciding to start an end-of-line comment immediately after a '+', with no intervening whitespace. As well, '+#' is just as easy to type as '#+'. Heck, while I like the bracketing idea, you could even say that any comment that begins with '+#' followed immediately by a non-bracketing character is an inline comment that will be terminated by the first '#+' sequence it finds: #end-of-line comment #(end-of-line) comment #+end-of-line comment #+(end-of-line) comment +# embedded comment #+ +#(embedded comment) I'm not picky as to the choice of the additional character; but if you're going to add it in, add it in where it will cause the least amount of trouble: just before the '#'. > I'd also change the terminology from "embedded" comments to "extended" > comments. toMAYto, toMAHto. -- Jonathan "Dataweaver" Lang
