15

Possible Duplicate:
Why do most programming languages not nest block comments?

Most languages I've worked with don't have support for recursive/nested comments.

  1. Is there any reason why language designers would choose not to implement this?
  2. Is it deceptively complex?
  3. Would it have undesired results?

I know there could be issues such as:

/*
    string Str = "aslfkalfksnflkn/*aslkfasnflkn";

*/

Console.WriteLine("asdoadokn");

However, we could still get the same issue with non-recursive ones (consider */ in a string in a comment) so i don't feel that's a good argument against.

Community
  • 1
George Duckett
  • 511
  • 6
  • 16
  • Let's ask back first: is there any compelling reason to implement it? As you note, there are tricky cases to cater for, so the feature should bring enough benefits to justify the effort to implement it in the first place. – Péter Török Oct 26 '11 at 08:32
  • 4
    Yes, i comment code with /* */, sometimes (tempoarily) i want to comment a large chunk with that within it. I don't want to have to rely on the IDE to do this (which would be awkward when uncommenting, as it should leaving the original comment block there). – George Duckett Oct 26 '11 at 08:33
  • 2
    I argue those tricky cases don't need to be catered for (in my example i don't see a difference between understanding what happens when we put a ****/ within a string within a comment (as we have to currently) and understanding what happens when we put a /**** in a string either) – George Duckett Oct 26 '11 at 08:38
  • I understand you personally would like to have it. I hope you too understand that mainstream languages aren't supposed to be designed to satisfy individual persons' desires. Is there any widely experienced, serious enough problem for which the best solution is recursive comments? IMHO your problem is more appropriate to be solved by your IDE. – Péter Török Oct 26 '11 at 08:40
  • 3
    I don't think i'm alone in wanting recursive comments, but you're right, i'm probably in too small a minority. – George Duckett Oct 26 '11 at 08:41
  • You aren't a minority in the sense that probably many of us have experienced some frustration with this issue sometimes (including myself). However, I personally have never felt it really so grave a problem that it would cry out for a "standard" solution. But that's just my 2 cents - others may feel differently. – Péter Török Oct 26 '11 at 08:47
  • 1
    Many IDE's that I've used have extensions or similar for commenting blocks of code, including where there are comments in that block. This is usually done by prefixing every line with "//", or placing "/* ... */" around each line. Those IDE's include the ability to add and remove such comment decoration, so its not been an issue. – quickly_now Oct 26 '11 at 09:04
  • I didn't get your question at first. I'm pretty sure what you want aren't [recursive](http://en.wikipedia.org/wiki/Recursion) comments. Perhaps [composition](http://en.wikipedia.org/wiki/Object_composition) is a better term to use. – Steven Jeuris Oct 26 '11 at 09:20
  • 3
    @George Duckett: To comment out chunks of code it is easier to use: `#if 0 #endif` – Martin York Oct 26 '11 at 09:33
  • @Steven, question updated (not sure about composition, used Nesting) – George Duckett Oct 26 '11 at 09:37
  • @GeorgeDuckett: nesting is perfect! ;p – Steven Jeuris Oct 26 '11 at 09:39
  • 3
    @Loki: I suppose we all know the workarounds. I understood this question to ask why they are necessary. – sbi Oct 26 '11 at 10:35
  • As a sidenote, this question was asked yesterday on SO: http://stackoverflow.com/questions/7872981/language-support-for-recursive-comments – xanatos Oct 26 '11 at 12:04
  • @xanatos, yes, by me. I'm not sure i framed the question as well as i could have, and didn't think it could be salvaged given the answers i'd already received would be relevant to a re-worded question so i decided to post here (deliberately not posting the link to the old question so as not to alter possible answers). – George Duckett Oct 26 '11 at 12:10
  • @LokiAstari, that only works if the language in question implements it. AFAIK, for example Java has no similar construct, yet uses C/C++-style `/* */` and `//` comments. – user Oct 26 '11 at 14:16

7 Answers7

28

The problem is that recursive comments force you to actually parse the comments section, pushing it outside the scope of a normal lexer and possibly introducing more problems.

As a refresher: A compiler usually has a number of distinct stages with different jobs, and the first stages are the lexer, which gets the input program and separates it into a sequence of tokens (each of which contains a keyword, and identifier or an operator), and the parser, which structures this sequence of tokens into an abstract syntax tree (AST).

For the scope of a lexer, remember that lexing can normally be done by regular expressions. Bracket-like structures like recursive comments cannot be parsed by regular expressions (see context-free grammars), so the lexer would have to have much additional complexity, e.g. would need to be implemented via a recursive-descent parser.

Additionally, for C and similar languages (who most famously used the /**/ comment syntax) the need never arose to comment out large chunks of code, since they had the pre-processor and unused chunks of code were just wrapped by

#if 0
....
#endif

which circumvented the parsing problem by delegating the problem to a second, much simpler compiler (the pre-processor).

Summarizing: Because recursive comments would make compiling more complicated, it's usually disallowed, and only languages with C-style comments, but without a preprocessor, really need it. That Java is amongst them is unfortunate, of course.

Edit: This doesn't mean recursive comments would be impossible or even very hard to do. You could use a recursive-descent lexer or could have a preprocessor before the lexer for filtering out comments. However, both approaches come with considerable cost compared to the standard model (use RE to auto-build the lexer and an EBNF to auto-build the parser), and the gain is pretty small.

thiton
  • 5,348
  • 1
  • 27
  • 26
  • 6
    I don't think that the complexity-of-compiler argument holds. See [my answer](http://programmers.stackexchange.com/questions/116330/language-support-for-recursive-comments/116339#116339). – sbi Oct 26 '11 at 09:33
  • D managed by adding it to the parser http://www.d-programming-language.org/lex.html#comment – ratchet freak Oct 26 '11 at 11:21
  • 1
    @ratchetfreak: That page is describing the lexical analyzer - the lexer. That page is an excellent example how a simple thing like a lexer can be blown up when including comments :-). – thiton Oct 26 '11 at 11:26
9

I'm with you on this. When you work with large, old code bases, then those are littered with comments regarding hacks, commented out code, and other dirt and grit, let alone C interfaces documented in /*...*/ comments. If you need to comment out some of that, using /*...*/ comments is almost never an option, because they do not nest.

I don't believe "further complicating the compiler" is a reason either, because compared to the complexity of C++, parsing comments for /*, */ (and maybe //) should be laughably easy. In fact, I seem to remember Borland C++ (in the 90s) offering the option to parse nested comments - and that compiler used to be known for its lighting speed.

But the problem with non-standard solutions is that you cannot use them if you might have to port your code later. (And, in C++, who would ever rule out that?)

So I agree that it would be an improvement if this was standardized.

In the meantime, I use // comments to comment out chunks of code. Fortunately, most modern editors/IDEs have an option to apply this to several lines at once.

sbi
  • 9,992
  • 6
  • 37
  • 56
  • 3
    +1 _"compared to the complexity of C++, parsing comments for /*, */ (and maybe //) should be laughably easy."_ I was wondering how valid [thiton's answer](http://programmers.stackexchange.com/questions/116330/language-support-for-recursive-comments/116333#116333) actually is. Can't verify it without some extensive reading. – Steven Jeuris Oct 26 '11 at 09:35
  • 1
    @sbi: The problem with parsing comments in a compiler is that you have three options: Do it in the lexer, in the parser, or add a third stage before the lexer. I explained why (a) is not an option. (b) isn't either because comments can appear **anywhere** and would make it impractical to build an EBNF grammar for your language because every rule would need comment variants. Really, try to implement a recursive-descent parser that also accepts comments, and you'll see just how much complexity that adds. (c) seems quite an overkill. – thiton Oct 26 '11 at 09:38
  • @thiton: Yet, what was probably the fastest C++ compiler of the pre-standard C++ era did parse nested comments. And it even implemented templates on par with cfront at the time, mind you. (FWIW, I once wrote a line counter that would (as an option) parse nested comments.) – sbi Oct 26 '11 at 09:42
  • 1
    @sbi: It's not about speed here. The computational cost of parsing these comments is probably negligible. It's about complexity: You have to push up the lexer complexity by one Chomsky, obfuscate the parser, or add another stage to an already well-staged process. The first and third options are *doable*, sure, but IMHO not worth it. – thiton Oct 26 '11 at 10:01
  • 3
    @thiton: One last time: I suppose that, considering the complexity of C++, parsing nested comments would be neglectable. This might, however, be different for language like C#, which have a comparatively simple syntax and parse quite fast. – sbi Oct 26 '11 at 10:34
  • @sbi: I agree, it seems we are going circles. As a final quip: The complexity of parsing nested comments is small in comparison to the complexity of compiling C++. And the power of nested comments is small in comparison to the power of C++ :-). – thiton Oct 26 '11 at 10:38
  • @thiton: Hits the nail on the head. It's not a matter of comparing how complex two things (parsing C++ and parsing code with nested comments) are, because you ignore their *value*. There is little that can be accomplished with nested or inline (as in *in the line*, not *on the line*) comments that can't be accomplished with ordinary comments with minimal changes, whereas there is quite a lot that can be accomplished with C++ that cannot be accomplished (without major changes, of course; they're both turing-complete). – Adam Robinson Oct 26 '11 at 16:44
  • 2
    @AdamRobinson: I would vastly prefer to be able to comment out code using `/* ... */` comments rather than `//`, and see a lot of value in it. – sbi Oct 28 '11 at 21:49
  • @sbi: I guess we all have different priorities; I can understand how it could be useful, but I don't think that (personally) I'd want anyone putting in the time to make that work instead of something else. – Adam Robinson Oct 28 '11 at 21:56
6

I modified a C compiler to do this once, it wasn't terribly hard. It's all taken care of in the lexical scanner, so you don't have to muck about with the guts of the parser. It's really just a matter of keeping track of the nesting level and ignoring anything within string delimiters.

TMN
  • 11,313
  • 1
  • 21
  • 31
3

Comments that span over multiple lines should be the exception, not the rule.

Even in C, I use C++ style // instead of standard /* */.

If I absolutely need to comment out a large portion of code, I use #if 0 preprocessor directive, which supports nesting.

mouviciel
  • 15,473
  • 1
  • 37
  • 64
  • 2
    In C++ I used to regularly hunt down cryptic parse errors by binary approximation through commenting out huge chunks (i.e. half the file) of code. With more experience in C++, more understanding of the quirks of the language and the mind of the compilers, this became less and less necessary, but with template meta-programming I still sometimes comment out a whole chunks of code (containing a bunch of specializations) in my struggle to grasp what the compiler is crying about. – sbi Oct 26 '11 at 09:36
  • If you are using `//` comments then it isn't C, but C-style C++ (or something to that effect). – user Oct 26 '11 at 14:17
  • 5
    This is [C99](http://en.wikipedia.org/wiki/C_(programming_language)#C99). – mouviciel Oct 26 '11 at 14:24
3

Newspeak has structured comments which can nest. And it has a very simple grammar, so it is obviously not "deceptively complex".

Jörg W Mittag
  • 101,921
  • 24
  • 218
  • 318
  • Better comment this on [sbi's answer](http://programmers.stackexchange.com/questions/116330/language-support-for-recursive-nested-comments/116339#116339). – Steven Jeuris Oct 26 '11 at 09:40
  • 1
    @Steven: I think this very much warrants its own answer. `+1` from me. – sbi Oct 26 '11 at 09:43
  • 1
    @sbi: So every language which supports nested comments is a separate answer? Oh well, that's a meta discussion. :) – Steven Jeuris Oct 26 '11 at 09:45
1

This is recursion:

public void recursion()
{
    recursion();
}

I have no idea what recursive comments would look like.

Nested comments on the other hand, would make sense, and actually already works to some extent. You can nest single line comments inside multiple line comments.

/* No longer use this!
// This is a method.
public void method()
{
}
*/

Supporting what you are asking, from the point of perspective of the programmer, would make perfect sense.

/* No longer use this!
// This is a method.
public void method()
{
    /* Disabled!
       doInterestingStuff();
       ...
    */
}
*/

Considering that programming languages are just tools in which programmers can express their intentions, supporting this intention would be an added value.

I can't comment on the technical aspects by heart, but it looks like some of the other answers already provided information on that.

Steven Jeuris
  • 5,804
  • 1
  • 30
  • 52
  • 2
    Recursive comment are those that require recursive parsing. `:)` – sbi Oct 26 '11 at 09:37
  • 3
    @sbi: Which _could_ be solved by using recursive parsing. A simple algorithm which increases a count upon finding `/*`, and decreases it upon finding `*/` would work as well. – Steven Jeuris Oct 26 '11 at 09:48
  • 3
    Once we're splitting hair, this could still be considered recursive parsing, though implemented non-recursively. `:)` – sbi Oct 26 '11 at 10:36
1

One reason is probably compatibility with existing codebases; C-like languages typically do everything just like C did, even stupid things like 031==25 (octal literals, who ever needed them?)

Another reason is more philosophical: A comment starts with (e.g.) /* and ends with the next */, and whatever is in between those, doesn't matter at all. Nested comments require defining a syntax for comments, too.

BTW, if you don't need that piece code anymore, why not just remove it entirely and leave it to the VCS to keep the older version? Commented code is a code smell.

user281377
  • 28,352
  • 5
  • 75
  • 130
  • 1
    `(oktal literals, who ever needed them?)` if you had started your career 20 years earlier, you would know that. I prefer octal up to day with the chmod command. – Ingo Oct 26 '11 at 16:10