Author: larry
Date: Sat Apr 15 11:25:52 2006
New Revision: 8699

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

Log:
Updated statement-level block syntax to favor statement block over arg block.
(Must use old-fashioned parens around conditional or args otherwise.)


Modified: doc/trunk/design/syn/S04.pod
==============================================================================
--- doc/trunk/design/syn/S04.pod        (original)
+++ doc/trunk/design/syn/S04.pod        Sat Apr 15 11:25:52 2006
@@ -12,9 +12,9 @@
 
   Maintainer: Larry Wall <[EMAIL PROTECTED]>
   Date: 19 Aug 2004
-  Last Modified: 10 Apr 2006
+  Last Modified: 15 Apr 2006
   Number: 4
-  Version: 14
+  Version: 15
 
 This document summarizes Apocalypse 4, which covers the block and
 statement syntax of Perl.
@@ -60,10 +60,27 @@
     my $x = $x;
 
 will no longer see the value of the outer C<$x>; you'll need to say
+either
 
     my $x = $OUTER::x;
 
-instead.  (It's illegal to declare C<$x> twice in the same scope.)
+or
+
+    my $x = OUTER::<$x>;
+
+instead.
+
+If you declare a lexical twice in the same scope, it is the same lexical:
+
+    my $x;
+    my $x;
+
+If you've referred to C<$x> prior to the first declaration, and the compiler
+tentatively bound it to C<$OUTER::x>, then it's an error to declare it, and
+the compiler is allowed to complain at that point.  If such use can't
+be detected because it is hidden in an eval, then it is erroneous, since
+the C<eval()> compiler might bind to either C<$OUTER::x> or the subsequently
+declared "C<my $x>".
 
 As in Perl 5, "C<our $foo>" introduces a lexically scoped alias for
 a variable in the current package.
@@ -143,10 +160,8 @@
        ...
     }
 
-Conditional statement modifiers also work as in Perl 5.  So do the
-implicit conditionals implied by short-circuit operators.  And there's
-a new C<elsunless> in Perl 6--except that you have to spell it C<elsif not>.
-C<:-)>
+Conditional statement modifiers work as in Perl 5.  So do the
+implicit conditionals implied by short-circuit operators.
 
 =head1 Loop statements
 
@@ -289,7 +304,10 @@
 
 Although a bare block is no longer a do-once loop, it still executes
 immediately as in Perl 5.  If you wish to return a closure from a
-function, you must use an explicit C<return>.
+function, you must use an explicit prefix such as C<return> or C<sub>
+or C<< -> >>.  (Use of a placeholder parameter is deemed insufficiently
+explicit because it's not out front where it can be seen.  You can, of
+course, use a placeholder parameter if you also use C<return>.)
 
 =head1 Switch statements
 
@@ -592,8 +610,8 @@
 parentheses aren't necessary around C<EXPR> because the whitespace
 between C<EXPR> and the block forces the block to be considered a
 block rather than a subscript.  This works for all control structures,
-not just the new ones in Perl 6.  A bare block where an operator
-is expected is always considered a statement block if there's space
+not just the new ones in Perl 6.  A top-level bare block
+is always considered a statement block if there's space
 before it:
 
     if $foo { ... }
@@ -602,11 +620,31 @@
     while $more { ... }
     for 1..10 { ... }
 
-(You can still parenthesize the expression argument for old times' sake,
-as long as there's a space between the closing paren and the opening
-brace.)
+You can still parenthesize the expression argument for old times'
+sake, as long as there's a space between the closing paren and the
+opening brace.  You I<must> parenthesize the expression if there is
+a bare block that would be misinterpreted as the statement's block.
+This is regardless of whether a term or operator is expected where
+the bare block occurs.  (A block inside brackets, or used as as
+postcircumfix is fine, though.)  Any block with whitespace
+in front of it will be taken as terminating the conditional, even if
+the conditional expression could take another argument.  Therefore
+
+    if -e { say "exists" } { extra() }
+
+is always parsed as
+
+    if (-e) { say "exists" }; { extra() }
+
+rather than
+
+    if (-e { say "exists" }) { extra() }
+
+Apart from that, it is illegal to use a bare closure where an
+operator is expected.  (Remove the whitespace if you wish it to be
+a postcircumfix.)
 
-On the other hand, anywhere a term is expected, a block is taken to
+Anywhere a term is expected, a block is taken to
 be a closure definition (an anonymous subroutine).  If the closure
 appears to delimit nothing but a comma-separated list starting with
 a pair (counting a single pair as a list of one element), the closure
@@ -627,29 +665,32 @@
     $hashref = hash("a", 1);
 
 If a closure is the right argument of the dot operator, the closure
-is interpreted as a hash subscript, even if there is space before the dot.
+is interpreted as a hash subscript.
 
     $ref = {$x};       # closure because term expected
-    if $term{$x}       # subscript because operator expected
+    if $term{$x}       # subscript because postfix expected
     if $term {$x}      # expression followed by statement block
-    if $term .{$x}     # valid subscript (term expected after dot)
+    if $term.{$x}      # valid subscript with dot
+    if $term. .{$x}    # valid subscript with "long dot"
 
 Similar rules apply to array subscripts:
 
     $ref = [$x];       # array composer because term expected
-    if $term[$x]       # subscript because operator expected
+    if $term[$x]       # subscript because postfix expected
     if $term [$x]      # syntax error (two terms in a row)
-    if $term .[$x]     # valid subscript (term expected after dot)
+    if $term.[$x]      # valid subscript with dot
+    if $term. .[$x]    # valid subscript with "long dot"
 
 And to the parentheses delimiting function arguments:
 
     $ref = ($x);       # grouping parens because term expected
     if $term($x)       # function call because operator expected
     if $term ($x)      # syntax error (two terms in a row)
-    if $term .($x)     # valid function call (term expected after dot)
+    if $term.($x)      # valid function call with dot
+    if $term. .($x)    # valid function call with "long dot"
 
-Outside of any kind of expression brackets, a trailing curly on a
-line by itself (not counting whitespace or comments) always reverts
+Outside of any kind of expression brackets, a final closing curly
+on a line (not counting whitespace or comments) always reverts
 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

Reply via email to