[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 C: + +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 C 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 C holding an C object does not flatten. Hence $bar = @bar; -push @foo, $bar; +@foo.push($bar); merely pushes a single C 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 C's signature flattens the C 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 C<0+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 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 C<0+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. Thanks, Audrey
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 C<0+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 C<0+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 C 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 C<1+2+3> so IMHO C<[,](1,2,3)> should be same as C<1,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 C category:
macro statement_control: ($expr, &ifblock) {...}
macro statement_control: ($expr, &whileblock) {...}
@@ -879,8 +879,8 @@
the start of a statement. To embed a statement in an expression you
must use something like C or C.
-$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: >> does not preclude us from
also defining a C<< prefix: >> that I be used within an expression:
@@ -895,7 +895,7 @@
You could also conceivably define a C<< prefix: >>, but then you may not
get what you want when you say:
-.print if $foo;
+die if $foo;
since C<< prefix: >> would hide C<< statement_modifier: >>.
