[svn:perl6-synopsis] r12340 - doc/trunk/design/syn
Author: larry Date: Fri Sep 22 23:40:54 2006 New Revision: 12340 Modified: doc/trunk/design/syn/S06.pod Log: clarified that prefix: ops with multiple args default to listop precedence Modified: doc/trunk/design/syn/S06.pod == --- doc/trunk/design/syn/S06.pod(original) +++ doc/trunk/design/syn/S06.podFri Sep 22 23:40:54 2006 @@ -13,9 +13,9 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 21 Mar 2003 - Last Modified: 20 Sept 2006 + Last Modified: 22 Sept 2006 Number: 6 - Version: 56 + Version: 57 This document summarizes Apocalypse 6, which covers subroutines and the @@ -1762,7 +1762,8 @@ default to named unary precedence despite declaring a prefix operator. Likewise postfix operators that look like method calls are forced to -default to the precedence of method calls. +default to the precedence of method calls. Any prefix operator that +requires multiple arguments default to listop precedence. =item Cis assoc
[svn:perl6-synopsis] r12342 - doc/trunk/design/syn
Author: larry Date: Fri Sep 22 23:45:40 2006 New Revision: 12342 Modified: doc/trunk/design/syn/S06.pod Log: Last ci had typo and was unclear about whether it applied only to identifiers. Modified: doc/trunk/design/syn/S06.pod == --- doc/trunk/design/syn/S06.pod(original) +++ doc/trunk/design/syn/S06.podFri Sep 22 23:45:40 2006 @@ -1763,7 +1763,8 @@ default to named unary precedence despite declaring a prefix operator. Likewise postfix operators that look like method calls are forced to default to the precedence of method calls. Any prefix operator that -requires multiple arguments default to listop precedence. +requires multiple arguments defaults to listop precedence, even if it +is not an identifier. =item Cis assoc
[svn:perl6-synopsis] r12346 - doc/trunk/design/syn
Author: audreyt Date: Sat Sep 23 01:05:45 2006 New Revision: 12346 Modified: doc/trunk/design/syn/S03.pod Log: * S03: Cleanup capture-exploding examples such that |@foo always simply put @foo's elements as positional arguments, regardless of whether @foo[0] contains a Hash. (On the other hand, [,] @foo will still happily turn @foo[0] into named argument.) Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podSat Sep 23 01:05:45 2006 @@ -12,9 +12,9 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 8 Mar 2004 - Last Modified: 20 Sept 2006 + Last Modified: 23 Sept 2006 Number: 3 - Version: 67 + Version: 68 =head1 Changes to Perl 5 operators @@ -911,7 +911,7 @@ as if they'd been placed there directly. @args = [EMAIL PROTECTED],1,2,3; -push [,] @args;# same as push @foo,1,2,3 +push [,] @args;# same as push(@foo: 1,2,3) See S06 for more. @@ -1311,33 +1311,39 @@ is equivalent to: -push @foo, @bar; +push @foo: @bar; -as is this: +which is just another way to write: -my $args = \(@foo, @bar);# construct a Capture object -push |$args; +@foo.push(@bar); -The C| sigil functions as a unary form of the C[,] -list operator, so we could have written the earlier example as: +The C| sigil functions as a unary form of the C[,] list operator, +so the examples above can also be written as. -my @args = [EMAIL PROTECTED], @bar; -push |@args; +my $args = \(@foo: @bar); # construct a Capture object +push |$args;# push(@foo: @bar) + +Unlike C[,], C| does not flatten its argument, but instead directly +converts its argument into a CCapture: + +my @args = \$x, 1, 2, 3; +say [,] @args; # say($x: 1, 2, 3); +say |@args; # say(\$x, 1, 2, 3); -To the extent possible, the C| will treat its argument as -a CCapture even if it isn't. +Because of this, C|%args always produces named arguments, and +C|@args always produces positional arguments. In list context, a CScalar holding an CArray object does not flatten. Hence $bar = @bar; -push @foo, $bar; +@foo.push($bar); merely pushes a single CArray object onto C@foo. You can explicitly flatten it in one of these ways: -push @foo, @$bar; -push @foo, $bar[]; -push @foo, |$bar; +@foo.push(@$bar); +@foo.push($bar[]); +@foo.push(|$bar); Those three forms work because the slurpy array in Cpush's signature flattens the CArray object into a list argument. @@ -1382,7 +1388,7 @@ automatically exploded into their various parts, as if you'd said: my \$capture := func(); -push [,] $$capture: @$capture, %$capture; +push($$capture: @$capture, %$capture); or some such. The C[,] then handles the various zones appropriately depending on the context. An invocant only makes sense as the first
Re: [svn:perl6-synopsis] r12346 - doc/trunk/design/syn
On 9/23/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: @args = [EMAIL PROTECTED],1,2,3; -push [,] @args;# same as push @foo,1,2,3 +push [,] @args;# same as push(@foo: 1,2,3) I don't quite understand this. Shouldn't C[,] @args be equivalent to C[EMAIL PROTECTED],1,2,3 just as C[+] 0,1,2,3 is equivalent to C0+1+2+3? So why is there C: instead of C, after C@foo? Does this have something to do with the fact that C@args is C[EMAIL PROTECTED],1,2,3 and not C@foo,1,2,3? -- Markus Laire
Re: [svn:perl6-synopsis] r12346 - doc/trunk/design/syn
在 Sep 24, 2006 12:21 AM 時，Audrey Tang 寫到： 在 Sep 23, 2006 8:36 PM 時，Markus Laire 寫到： On 9/23/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: @args = [EMAIL PROTECTED],1,2,3; -push [,] @args;# same as push @foo,1,2,3 +push [,] @args;# same as push(@foo: 1,2,3) I don't quite understand this. Shouldn't C[,] @args be equivalent to C[EMAIL PROTECTED],1,2,3 just as C[+] 0,1,2,3 is equivalent to C0+1+2+3? So why is there C: instead of C, after C@foo? Does this have something to do with the fact that C@args is C[EMAIL PROTECTED],1,2,3 and not C@foo,1,2,3? Exactly. Per this interpretation, [EMAIL PROTECTED] is shorthand for \(@foo :), and [,] would first flatten the contents of @arg, and then process each one; if an element is Capture, it is joined into the current arglist; if it's not, then it's made a simple positional. I wasn't sure about this treatment, so I checked on #perl6 with Larry; an alternative is to treat the elements of @foo always as positional arguments, but that will make the two [,] calls below nonequivalent: my @args = [EMAIL PROTECTED], 1, 2, 3; [,] @args; [,] [EMAIL PROTECTED], 1, 2, 3; I'd prefer to make them equivalent, on the principle that all listops conceptually flatten+concat their arguments first, and then process each element regardless of its origin. On the other hand, it can also be argued that [,] TERM, TERM, TERM; is shorthand for |(TERM), |(TERM), |(TERM) and the treatment will depend solely on TERM's scalar-context type without considering list flattening. Per that interpretation, indeed these two need not be equivalent: my @args = [EMAIL PROTECTED], 1, 2, 3; [,] @args; # four positionals, same as |@args [,] [EMAIL PROTECTED], 1, 2, 3; # one invocant, three positionals, same as | ([EMAIL PROTECTED]), |(1), |(2), |(3) however, having a listop that does not do flatten+concat doesn't feel quite right, so I'd still like the flatten-concat-explode model as currently specced. Thanks, Audrey
Re: [svn:perl6-synopsis] r12346 - doc/trunk/design/syn
On 9/23/06, Audrey Tang [EMAIL PROTECTED] wrote: 在 Sep 23, 2006 8:36 PM 時，Markus Laire 寫到： On 9/23/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: @args = [EMAIL PROTECTED],1,2,3; -push [,] @args;# same as push @foo,1,2,3 +push [,] @args;# same as push(@foo: 1,2,3) I don't quite understand this. Shouldn't C[,] @args be equivalent to C[EMAIL PROTECTED],1,2,3 just as C[+] 0,1,2,3 is equivalent to C0+1+2+3? So why is there C: instead of C, after C@foo? Does this have something to do with the fact that C@args is C[EMAIL PROTECTED],1,2,3 and not C@foo,1,2,3? Exactly. Per this interpretation, [EMAIL PROTECTED] is shorthand for \(@foo :), and I think that this shorthand should be mentioned somewhere. From some of the examples I thought that C[EMAIL PROTECTED], @bar would be equivalent to C\(@foo, @bar) [,] would first flatten the contents of @arg, and then process each one; if an element is Capture, it is joined into the current arglist; if it's not, then it's made a simple positional. I wasn't sure about this treatment, so I checked on #perl6 with Larry; an alternative is to treat the elements of @foo always as positional arguments, but that will make the two [,] calls below nonequivalent: my @args = [EMAIL PROTECTED], 1, 2, 3; [,] @args; [,] [EMAIL PROTECTED], 1, 2, 3; I'd prefer to make them equivalent, on the principle that all listops conceptually flatten+concat their arguments first, and then process each element regardless of its origin. Thanks, Audrey -- Markus Laire
Is [,] different from other Reduction operators?
S06 says: =head2 Flattening argument lists The reduce operator C[,] casts each of its arguments to a CCapture object, then splices each of those captures into the argument list it occurs in. The unary C| sigil has the same effect on a single argument. ... Does this mean that [,] is a special Reduction operator and doesn't work in the same way as other Reduction operators do? I don't quite understand what [,] actually does, but it seems to be so special that IMHO it shouldn't be a Reduction operator at all but something totally different. As an example, C[+](1,2,3) is same as C1+2+3 so IMHO C[,](1,2,3) should be same as C1,2,3 but S06 says that it becomes C\(1,2,3). -- Markus Laire
[svn:perl6-synopsis] r12347 - doc/trunk/design/syn
Author: audreyt
Date: Sat Sep 23 20:48:58 2006
New Revision: 12347
Modified:
doc/trunk/design/syn/S04.pod
Log:
* S04: Wording and examples cleanup; no semantic changes.
Modified: doc/trunk/design/syn/S04.pod
==
--- doc/trunk/design/syn/S04.pod(original)
+++ doc/trunk/design/syn/S04.podSat Sep 23 20:48:58 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 19 Aug 2004
- Last Modified: 15 Sep 2006
+ Last Modified: 24 Sep 2006
Number: 4
- Version: 39
+ Version: 40
This document summarizes Apocalypse 4, which covers the block and
statement syntax of Perl.
@@ -869,7 +869,7 @@
Final blocks on statement-level constructs always imply semicolon
precedence afterwards regardless of the position of the closing curly.
Statement-level constructs are distinguished in the grammar by being
-declared in the statement syntactic group:
+declared in the Cstatement_control category:
macro statement_control:if ($expr, ifblock) {...}
macro statement_control:while ($expr, whileblock) {...}
@@ -879,8 +879,8 @@
the start of a statement. To embed a statement in an expression you
must use something like Cdo {...} or Ctry {...}.
-$x = do { given $foo { when 1 {2} when 3 {4} }} + $bar;
-$x = try { given $foo { when 1 {2} when 3 {4} }} + $bar;
+$x = do { given $foo { when 1 {2} when 3 {4} } } + $bar;
+$x = try { given $foo { when 1 {2} when 3 {4} } } + $bar;
The existence of a C statement_control:BEGIN does not preclude us from
also defining a C prefix:BEGIN that Ican be used within an expression:
@@ -895,7 +895,7 @@
You could also conceivably define a C prefix:if , but then you may not
get what you want when you say:
-.print if $foo;
+die if $foo;
since C prefix:if would hide C statement_modifier:if .
