[svn:perl6-synopsis] r10304 - doc/trunk/design/syn

Author: larry
Date: Wed Jul 19 11:21:01 2006
New Revision: 10304

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

Log:
Generalize long dot to "unspace" to futureproof against grammar mods.
(And also to allow suppression of any curly-at-the-end-of-line misparse. :)


Modified: doc/trunk/design/syn/S02.pod
==============================================================================
--- doc/trunk/design/syn/S02.pod	(original)
+++ doc/trunk/design/syn/S02.pod	Wed Jul 19 11:21:01 2006
@@ -12,9 +12,9 @@
 
   Maintainer: Larry Wall <larry@wall.org>
   Date: 10 Aug 2004
-  Last Modified: 18 July 2006
+  Last Modified: 19 July 2006
   Number: 2
-  Version: 51
+  Version: 52
 
 This document summarizes Apocalypse 2, which covers small-scale
 lexical items and typological issues.  (These Synopses also contain
@@ -173,6 +173,17 @@
 
 =item *
 
+In fact, any whitespace (including comments) may be hidden by prefixing
+it with C<\>.  It does not have to end with a dot.  It's just that
+the normal use of a you-don't-see-this-space is typically to put
+a dotted postfix on the next line.  But it also lets you continue
+the line in any situation where a newline might confuse the parser,
+regardless of the currently installed parser.  (Unless, of course,
+you override the unspace rule itself...)  Although we say that the
+unspace hides the whitespace from the parser, line numbers are still counted.
+
+=item *
+
 In general, whitespace is optional in Perl 6 except where it is needed
 to separate constructs that would be misconstrued as a single token or
 other syntactic unit.  (In other words, Perl 6 follows the standard
@@ -210,9 +221,13 @@
     .++
 
     $x\ 	# comment
-    		# more comment
+    		# inside long dot
     .++
 
+    $x\ 	# comment
+    		# inside "unspace"
+    ++		# (but long dot may be preferred...)
+
     $x\#『	comment
     		more comment
     』.++
@@ -266,7 +281,7 @@
 postfix dot will be taken to be the start of some kind of method call
 syntax, whether long-dotty or not.  (The C<.123> form with a leading
 dot is still allowed however when a term is expected, and is equivalent
-to C<0.123>.)
+to C<0.123> rather than C<$_.123>.)
 
 =back
 

Modified: doc/trunk/design/syn/S03.pod
==============================================================================
--- doc/trunk/design/syn/S03.pod	(original)
+++ doc/trunk/design/syn/S03.pod	Wed Jul 19 11:21:01 2006
@@ -12,9 +12,9 @@
 
   Maintainer: Larry Wall <larry@wall.org>
   Date: 8 Mar 2004
-  Last Modified: 18 Jul 2006
+  Last Modified: 19 Jul 2006
   Number: 3
-  Version: 50
+  Version: 51
 
 =head1 Changes to existing operators
 
@@ -95,10 +95,14 @@
 =item * The scalar comma C<,> now constructs a C<List> object from its
 operands.  You have to use a C<[-1]> subscript to get the last one.
 
-=item * The backslash operator captures its arguments, and returns an
+=item * The unary backslash operator captures its arguments, and returns an
 object representing those arguments.  You can I<dereference> this object
 in several ways to retrieve different parts of the arguments; see the
-definition of C<Capture> in S02 for details.
+definition of C<Capture> in S02 for details.  (No whitespace is allowed
+after the backslash because that would instead start an "unspace", that is,
+an escaped sequence of whitespace or comments.  See S02 for details.
+However, oddly enough, because of that unspace rule, saying C<\\ $foo>
+turns out to be equivalent to C<\$foo>.)
 
 =item * The old scalar C<..> flipflop operator is now done with
 C<ff> operator.  (C<..> now always produces a C<Range> object
@@ -329,10 +333,11 @@
 of postfix operators.
 
 =item * A list operator's arguments are also terminated by a closure
-that is not followed by a comma or colon.  (And a semicolon is implied if
-the closure is the final thing on a line.)  This final closure may be
-followed by a postfix, in which case the postfix is applied to the result
-of the entire list operator.
+that is not followed by a comma or colon.  (And a semicolon is implied
+if the closure is the final thing on a line.  Use an "unspace" to
+suppress that.)  This final closure may be followed by a postfix,
+in which case the postfix is applied to the result of the entire
+list operator.
 
 =item * A function predeclared as 0-ary is never considered list
 operator, though it allows an optional set of empty parentheses.

Modified: doc/trunk/design/syn/S04.pod
==============================================================================
--- doc/trunk/design/syn/S04.pod	(original)
+++ doc/trunk/design/syn/S04.pod	Wed Jul 19 11:21:01 2006
@@ -12,9 +12,9 @@
 
   Maintainer: Larry Wall <larry@wall.org>
   Date: 19 Aug 2004
-  Last Modified: 16 July 2006
+  Last Modified: 18 July 2006
   Number: 4
-  Version: 27
+  Version: 28
 
 This document summarizes Apocalypse 4, which covers the block and
 statement syntax of Perl.
@@ -747,8 +747,10 @@
 to the precedence of semicolon whether or not you put a semicolon
 after it.  (In the absence of an explicit semicolon, the current
 statement may continue on a subsequent line, but only with valid
-statement continuators such as C<else>.  A modifier on a C<loop>
-statement must continue on the same line, however.)
+statement continuators such as C<else> that cannot be confused with
+the beginning of a new statement.  Anything else, such as a statement
+modifier (on, say, a C<loop> statement) must continue on the same line,
+unless the newline be escaped using the "unspace" construct--see S02.)
 
 Final blocks on statement-level constructs always imply semicolon
 precedence afterwards regardless of the position of the closing curly.
@@ -783,6 +785,14 @@
 
 since C<< prefix:<if> >> would hide C<< statement_modifier:<if> >>.
 
+Built-in statement-level keywords require whitespace between the
+keyword and the first argument, as well as before any terminating loop.
+In particular, a syntax error will be reported for C-isms such as these:
+
+    if(...) {...}
+    while(...) {...}
+    for(...) {...}
+
 =head1 Definition of Success
 
 Hypothetical variables are somewhat transactional--they keep their

• [svn:perl6-synopsis] r10304 - doc/trunk/design/syn by larry