8

I have a compiler homework question that wants me to draw a DFA for Pascal comments, but I have never (and probably never will) use Pascal. The question does not specify if we should use ANSI Pascal or Turbo Pascal, so I was going to do one for both.

Some Google searches showed me that Turbo Pascal allows nested comments as long as the same delimiter is not used, so {(*comment*)} is ok and so is (*{comment}*), but {{comment}} or (*(*comment*)*) are not ok. My question here is if a comment like {(*{comment}*)} or (*{(*comment*)}*) is ok since the same delimiters are not used in a row.

I also Googled to see if ANSI Pascal allowed nested comments, but I have not found a definitive answer. If ANSI Pascal does allow nested comments, what are the rules?

On a side note, I am not worried about the strange commenting convention of different starting and ending delimiters, a convention that is allowed in ANSI Pascal.

UPDATE:

I would like to be clear that I am not really concerned with how specific compilers handle Pascal comments, I am concerned with how a compiler SHOULD handle Pascal comments if that compiler adhered 100% to either the ANSI or TURBO Pascal standards.

Rob Kennedy
  • 161,384
  • 21
  • 275
  • 467
ubiquibacon
  • 10,451
  • 28
  • 109
  • 179
  • 1
    This seems like a question you should ask your instructor. Check your textbook, too. – Rob Kennedy Oct 01 '10 at 20:19
  • @Rob Kennedy my instructor and I did talk about this before I posted the question, and I already have the problem solved to his liking. The book was not looking for us to go this deep into the issue, but I like to be thorough. Additionally, as I stated in the question, the book is non-specific on what version of Pascal should be considered, and since the book is a Compiler book and not a Pascal book, the commenting conventions of the language are not explicitly defined, and that is what I am looking for in my question, and explicit definition. – ubiquibacon Oct 01 '10 at 20:59

4 Answers4

12

ISO 7185:1990 says this about comments in §6.1.8:

Where a commentary shall be any sequence of characters and separations of lines, containing neither } nor *), the construct

( '{' | '(*' ) commentary ( '*)' | '}' )

shall be a comment if neither the { nor the (* occurs within a character-string or within a commentary.

NOTES

  1. A comment may thus commence with { and end with *), or commence with (* and end with }.
  2. The sequence (*) cannot occur in a commentary even though the sequence {) can.

According to that, there's essentially just one kind of comment. Although you can start a comment with either { or (*, you can't use different sets of characters to "wrap" other comments. Turbo Pascal, on the other hand, has two kinds of comments, those that use braces and those that use parentheses.

If you have a brace-style comment and enclose it in a parenthesis-style comment to create (*{}*), ISO says the comment is (*{} with *) left over, which will be a syntax error in your code, whereas Turbo Pascal says the comment is (*{}*) with no text left over.

Neither style lets you wrap an already-wrapped comment in yet another set of comment delimiters. That's because once you wrap a comment, the "inner" comment ceases to be treated as a comment anymore. It's just ordinary text. If you have {(**)} and you want to wrap it in a parenthesis-style comment to make (*{(**)}*), ISO and Turbo Pascal both say the comment is (*{(**) with }*) left over.

In fpc and objfpc modes, Free Pascal supports nesting comments, so my most recent example would be accepted as a valid comment with no leftover text. The FPC documentation on the matter doesn't actually demonstrate that, though. It gives six examples of supposedly nested comments:

{ Comment 1 (* comment 2 *) }  
(* Comment 1 { comment 2 } *)  
{ comment 1 // Comment 2 }  
(* comment 1 // Comment 2 *)  
// comment 1 (* comment 2 *)  
// comment 1 { comment 2 }

But Turbo Pascal (or Delphi, for the last two lines), which we've already established doesn't support nesting, would accept all of those as perfectly valid comments! FPC really does support nested comments, but those examples don't illustrate it. Here are some examples of nested comments:

{ Comment 1 { comment 2 } }
(* Comment 1 (* comment 2 *) *)
{ Comment 1 (* comment 2 { comment 3 } *) }

I'd even argue that FPC's third and fourth examples are actually counterexamples to the claim that FPC supports nested comments. Those two lines shouldn't be complete comments at all. The // in the middle of the line introduces a comment that doesn't terminate until the end of the line (EOL). The EOL comes after the } and *), so the inner, slash-style comment can't possibly have terminated by the time we reach the brace or parenthesis delimiters. Just as <a> <b> </a> </b> is improperly nested XML, we have improperly nested comments: { // } EOL.

After further experimentation, I conclude that in FPC, only comments of the same type nest. For example, once you open a comment with {, the (* characters cease to be special. FPC will not open a parenthesis-style comment inside the brace-style comment. If it did, then {(*} would be a syntax error due to the unterminated parenthesis comment. We could explain this by saying that termination of inner comments is optional when the comments are heterogeneous, but it's a simpler explanation to say that the inner comment isn't detected as a comment at all. Once you open a brace-style comment, only braces have meaning. Furthermore, // doesn't actually start a slash-style comment when it's inside braces. That's a simpler explanation that to say that FPC allows slash-style comments to be improperly nested. You can either say that slash-style comments don't nest at all, or that slash-style comments nested within other slash-style comments share a single EOL terminator.

Your assignment probably meant for you to use the Turbo Pascal style, where the comment delimiters must match. It definitely didn't expect you to use the Free Pascal style since it would have made the assignment impossible to complete — a DFA cannot accept arbitrarily nested constructs.

Rob Kennedy
  • 161,384
  • 21
  • 275
  • 467
  • 2
    Now that you've summed up all *commenting*, I'd like to add in regard of the question that, in [1993](http://en.wikipedia.org/wiki/Pascal_%28programming_language%29#Standards) the ANSI standard have ceased to exist in behalf of the ISO standard. Whereas TURBO, is [regarded](http://pascal-central.com/extpascal.html#anchor-6) rather a non-standard Pascal. Non-standard or not, there seems to be no published specification of it. – Sertac Akyuz Oct 02 '10 at 01:09
  • thanks for the very descriptive answer! That made things much clearer. One thing though, where you say `I'd even argue that FPC's...` I am wondering if that is correct or not. I will use your own argument against you that `Comment delimiters differ from matryoshka dolls in that they change the interpretation of what's inside them`. Doesn't the starting comment delimiter of example 3 and 4 `"change the interpretation"` of the internal double-slash `//` comment? – ubiquibacon Oct 02 '10 at 07:34
  • @Sertac Akyuz good find about the ANSI standard now being the ISO standard and about Turbo Pascal being a dialect rather than a standard. – ubiquibacon Oct 02 '10 at 07:35
  • Rob: This is one of the reasons why Delphi packages often need rebalancing of comments in the header before FPC can compile them without commandline parameters. This because often the {$i whatever.inc} only changes to delphi mode, so above the includefile (the header) is in native FPC mode, and thus expects balancing. – Marco van de Voort Oct 02 '10 at 09:02
  • @Typoknig, when comments don't nest (as in ISO and Turbo), the first delimiter changes the interpretation of all further opening delimiters — the `{` causes `//` to no longer start comments. When comments *do* nest, an opening delimiter *shouldn't* change the meaning of other delimiters — a `{` wouldn't change the meaning of `//`. In FPC, where comments nest, we're told that `//` by itself starts a comment ending at EOL. When it's inside another comment, the rules change so the comment ends *before* EOL. In FPC, `{` may cause `//` to start a *different kind* of comment, but not detectably so. – Rob Kennedy Oct 02 '10 at 15:13
2

At least Delphi won't allow {(*{comment}*)} cause the first closing curly bracket will close the first opening curly bracket and not the last one. Same applies to your other sample.

Eugene Mayevski 'Callback
  • 45,135
  • 8
  • 71
  • 121
  • FPC have got no problem with either of the examples though, it also seems to allow to nest the same symbol i.e. `{{comment}}`. The [docs](http://www.freepascal.org/docs-html/ref/refse2.html) say there's some compiler mode dependancy. – Sertac Akyuz Oct 01 '10 at 20:11
  • @Sertac Akyuz I tried various comments in SciTE text editor and it tells me that `{{comment}}` is invalid. I don't know how much I can trust it though. I guess what is and what is not allowed all comes down to the compiler anyways, but I am wondering more about the standards (TURBO and ANSI) rather than what a specific compiler does or does not allow. – ubiquibacon Oct 01 '10 at 20:18
  • @typo - Fair enough. If you like have a look at [Pascal ISO 7185:1990](http://www.moorecad.com/standardpascal/iso7185.pdf) standard. That's the only official doc I can refer to. – Sertac Akyuz Oct 01 '10 at 20:34
0

in fpc (free pascal) : //... (...) {...}

shs.pas
  • 1
0

I think in the version of turbo pascal I used, nested comments were not supported, both of these would compile:

{(* }

{{ }

Some Google searches showed me that Turbo Pascal allows nested comments as long as the same delimiter is not used

Effectively, nested comments are "supported", because the alternate syntax is ignored by the compiler.

You could download a pascal compiler and write your dfa to support what that compiler supports. Use one of their example programs, and see if nested comments will compile.

Brian Maltzan
  • 1,327
  • 10
  • 12
  • 2
    I think that means nested comments are *not* supported. You cannot nest comments; a comment ends at the *first* comment-ending character, no matter how many comment-starting characters came before it. – Rob Kennedy Oct 01 '10 at 20:20
  • 1
    @Rob Kennedy I don't think that is 100% true for Turbo Pascal because `{(*comment*)}` is valid and so is `(*{comment}*)`. The INNER comment would end at it's matching delimiter in Turbo Pascal, and the OUTER comment would end at it's matching delimiter. That is because Turbo Pascal DOES NOT allow comments made with unmatched delimiters like `(*comment}` or `{comment*)`. – ubiquibacon Oct 01 '10 at 20:55
  • 1
    But @Typoknig, that doesn't mean comments are nested. Inside a comment, *all* other characters are ignored. The fact that some of those characters happen to look like Pascal's other comment characters is irrelevant. Once you have an "outer" comment, the "inner" comment *ceases to be a comment at all*. It's just plain text in there. – Rob Kennedy Oct 01 '10 at 21:18
  • @Rob Kennedy if that is not nesting then what is? A matryoshka doll inside a matryoshka doll is still a matryoshka doll. – ubiquibacon Oct 01 '10 at 22:50
  • 1
    @Typoknig, nesting is when the syntax rules for opening and closing comments are enforced even when you're already in a comment. If comments could nest, then `{(*}` would be a syntax error because the "inner" comment isn't terminated, and `{{}}` would *not* be a syntax error. Comment delimiters differ from matryoshka dolls in that they change the interpretation of what's inside them. For example, wrapping a variable declaration inside braces means that from the language's perspective, it's no longer a variable declaration; the compiler ignores it. – Rob Kennedy Oct 01 '10 at 23:19
  • typknig: what if you put text between the *) and } ? Maybe it just silently skips whitespace-closing comment aggregates. I agree with Rob btw that it is not true nesting. Nesting is _checked_ – Marco van de Voort Oct 02 '10 at 09:06