Author: larry
Date: Wed Aug 29 03:15:06 2007
New Revision: 14440

Modified:
   doc/trunk/design/syn/S02.pod

Log:
Block comments removed in favor of simple syntax error in case of ambiguity


Modified: doc/trunk/design/syn/S02.pod
==============================================================================
--- doc/trunk/design/syn/S02.pod        (original)
+++ doc/trunk/design/syn/S02.pod        Wed Aug 29 03:15:06 2007
@@ -12,9 +12,9 @@
 
   Maintainer: Larry Wall <[EMAIL PROTECTED]>
   Date: 10 Aug 2004
-  Last Modified: 13 Jun 2007
+  Last Modified: 29 Aug 2007
   Number: 2
-  Version: 112
+  Version: 113
 
 This document summarizes Apocalypse 2, which covers small-scale
 lexical items and typological issues.  (These Synopses also contain
@@ -147,51 +147,48 @@
 (There may be the I<visual appearance> of space for some double-wide
 characters, however, such as the corner quotes above.)
 
-An embedded comment is not allowed as the first thing on the line since it
-would instead be parsed as a block comment, as described next.
+An embedded comment is not allowed as the first thing on the line.
 
-=item *
-
-Unlike embedded comments, which are character-oriented, block comments
-are line-oriented.  To facilitate the common practice of commenting out
-sections of code by prefixing each line with C<#>, if the initial C<#>
-on the line is immediately followed by one or more opening brackets,
-it is treated as a line-oriented form of bracket quoting, and may
-be terminated I<only> by a line matching the corresponding close
-bracket, which (unlike embedded comments) must also be prefixed with
-an initial C<#>.  For example, a opening line matching
-
-    /^^ '#{' \s /
-
-it may be terminated I<only> by a line matching
-
-    /^^ '#}' \s /
-
-The entire final line counts as part of the comment.  It does
-not matter whether the intervening lines start with C<#> or not.
-Block comments may be nested within other block comments (with the
-same or differing brackets).  POD comments may also be nested within
-block comments.  (These are still visible to the POD parser; if you
-wish to comment out a block of mixed POD and Perl 6 code, either use a
-POD comment around it all, or prefix every line with C<#>.)  The parser
-must report mismatched openers or closers to prevent, for example,
-unwitting use of bare C<}> as a closer for an opening C<#{>.
-
-However, an unexpected closer is treated as a line-end comment, on the
-assumption that the opening bracket was at the end of its comment line
-in the K&R style:
-
-    #for @foo {
-    # ...
+    #sub foo                    # line-end comment
+    #{                          # ILLEGAL, syntax error
+    #   ...
     #}
 
-In addition to supporting the practice of commenting out code with
-line comments, an additional motivation for this is to promote human
-recognition of the end of the comment when the opener could be quite
-far away, without requiring that all intervening lines use C</^'#'/> comments.
-Also, using the ordinary embedded comment mechanism tends to be fragile
-in the face of strings containing bracket characters, and the probability
-of such bracket skew increases with the length of the commented code.
+If you wish to have a comment there, you must disambiguate it to
+either an embedded comment or a line-end comment.  You can put a
+space in front of it to make it an embedded comment:
+
+    #sub foo                    # line end comment
+     #{                         # okay, comment
+       ...                      # extends
+    }                           # to here
+
+Or you can put something other than a single C<#>
+to make it a line-end comment.  Therefore, if you are commenting out a
+block of code using the line-comment form, we recommend that you use
+C<##>, or C<#> followed by some whitespace, preferably a tab to keep
+any tab formatting consistent:
+
+    ##sub foo
+    ##{                         # okay
+    ##   ...
+    ##}
+
+    # sub foo
+    # {                         # okay
+    #    ...
+    # }
+
+
+    #       sub foo
+    #       {                   # okay
+    #          ...
+    #       }
+
+However, it's often better to use pod comments because they are
+implicitly line-oriented.  And if you have an intelligent syntax
+highlighter that will mark pod comments in a different color, there's
+less visual need for a C<#> on every line.
 
 =item *
 

Reply via email to