Front page | perl.perl6.language |
Postings from April 2006
[svn:perl6-synopsis] r8699 - doc/trunk/design/syn
From:
larry
Date:
April 15, 2006 11:26
Subject:
[svn:perl6-synopsis] r8699 - doc/trunk/design/syn
Message ID:
20060415182552.32CE9CBA6D@x12.develooper.com
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 <larry@wall.org>
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
-
[svn:perl6-synopsis] r8699 - doc/trunk/design/syn
by larry