A few do, but not any of the popular ones as far as I know. Is there something bad about nesting comments?
I plan to have block comments nest in the (small) language I'm working on, but I would like to know if this is a bad idea.
|
A few do, but not any of the popular ones as far as I know. Is there something bad about nesting comments? I plan to have block comments nest in the (small) language I'm working on, but I would like to know if this is a bad idea. |
|||||||||||
|
|
Because most of the implementations are using separate lexing and parsing stages, and for lexing they're using plain old regular expressions. Comments are treated as whitespaces - i.e., ignored tokens, and thus should be resolved entirely in a lexing pass. The only advantage of this approach is parsing speed. Numerous disadvantages include severe limitations on syntax (e.g., a need to maintain a fixed, context-independent set of keywords). |
|||||||||
|
|
It's perfectly possible to make a lexer that can handle nested comments. When it's eating whitespace, when it sees If comments can nest, then a downside is it's easy to get their ends unbalanced, and unless you have a fancy editor, it can invisibly hide code you assume is there. An upside of comments that don't nest is something like this:
where you can easily comment the code in or out by removing or adding the first line - a 1-line edit.
Of course, if that code itself contains a comment, this would break, unless you also allow C++-style |
|||||
|
|
Supporting nested block comments complicates the parser, which is both more work and it could increase the compile time. I guess it is not a very needed feature for a language, so it is better to use the time and effort on other improvements and optimizations. In my opinion simplicity is always a good thing in designing anything. Keep in mind that it is easier to add a feature than to remove it. Once you allow nested comments and there are programs out there using it, you won't be able to take them out without breaking compatibility. |
|||||
|
|
One probable reason is that nested comments must be handled by the parser, since the flavor of regular expressions commonly used in lexers don't support recursion. The simple ones can be eliminated as whitespace by the lexer, so they're simpler to implement in that way. |
|||||||||
|
|
A good point of nesting block comments is that you can comment out large portions of code easily (well, almost, unless you have the block comment end sequence in a string constant). An alternative method is to prepend a bunch of line with the line comment start sequence if you have an editor that supports it. Haskell has nested block comments, but most people dont seem to notice or to complain about it. I guess this is because people that do not expect nested comments tend to avoid them as this would be a lexical error in other languages. |
|||
|
|
|
Since nobody else mentioned it, I'll list a few languages that do support nested comments: Rexx, Modula-2, Modula-3, Oberon. Despite all the complaints here about difficulty and speed issues, none of those seem to have any huge problems. |
|||||
|
|
Who knows? I would guess because supporting nested comments is more work - you would have to maintain a stack of some sort, and because it complicates the language grammar. |
|||
|
|
|
Nested comments are mean extra work for the parser. Usually when you see the start of a comment you ignore everything until the end comment marker. I order to support nested comments you have to parse the text in the comments as well. The biggest issue though is that a programmer has to be careful to close all nested comments correctly or it will lead to compilation errors. Correctly implementing a compiler is something that can be done but keeping track of nested comments as a programmer is quite error prone and irritating. |
|||||
|