Author: larry
Date: Fri Apr 21 16:57:00 2006
New Revision: 8904
Modified:
doc/trunk/design/syn/S02.pod
doc/trunk/design/syn/S06.pod
Log:
Cleanups suggested by 'f++
Also renamed @; to @;_ so @;() isn't a special case from other sigils.
Modified: doc/trunk/design/syn/S02.pod
==============================================================================
--- doc/trunk/design/syn/S02.pod (original)
+++ doc/trunk/design/syn/S02.pod Fri Apr 21 16:57:00 2006
@@ -14,7 +14,7 @@
Date: 10 Aug 2004
Last Modified: 21 Apr 2006
Number: 2
- Version: 25
+ Version: 26
This document summarizes Apocalypse 2, which covers small-scale
lexical items and typological issues. (These Synopses also contain
@@ -400,9 +400,9 @@
Typically it's an array of bytes serving as a buffer. Bitwise
operations on a C<Buf> treat the entire buffer as a single large
integer. Bitwise operations on a C<Str> generally fail unless the
-C<Str> in question can provide an abstract C<Btr> interface somehow.
-Coercion to C<Btr> should generally invalidate the C<Str> interface.
-As a generic type C<Btr> may be instantiated as (or bound to) any
+C<Str> in question can provide an abstract C<Buf> interface somehow.
+Coercion to C<Buf> should generally invalidate the C<Str> interface.
+As a generic type C<Buf> may be instantiated as (or bound to) any
of C<buf8>, C<buf16>, or C<buf32> (or to any type that provide the
appropriate C<Buf> interface), but when used to create a buffer C<Buf>
defaults to C<buf8>.
Modified: doc/trunk/design/syn/S06.pod
==============================================================================
--- doc/trunk/design/syn/S06.pod (original)
+++ doc/trunk/design/syn/S06.pod Fri Apr 21 16:57:00 2006
@@ -15,7 +15,7 @@
Date: 21 Mar 2003
Last Modified: 21 Apr 2006
Number: 6
- Version: 26
+ Version: 27
This document summarizes Apocalypse 6, which covers subroutines and the
@@ -790,7 +790,24 @@
that is a variadic function, the pipe is received as part of its slurpy list.
So both of the calls above are equivalent to:
- grep { $_ % 2 } @data;
+ grep { $_ % 2 }, @data;
+
+Note that all such pipes (and indeed all lazy argument lists) supply
+an implicit promise that the code producing the lists may execute
+in parallel with the code receiving the lists. (Pipes, hyperops,
+and junctions all have this promise of parallelizability in common,
+but differ in interface. Code which violates these promises is
+erroneous, and will produce undefined results when parallelized.)
+In particular, a pipeline may not begin and end with the same array.
+(You may, however, assign to an array that is used within a pipeline
+on the right side of the assignment, since list assignment will clear
+and copy as necessary to make it work.) That is, this doesn't work:
+
+ @data <== grep { $_ % 2 } <== @data;
+
+but this does:
+
+ @data = grep { $_ % 2 } <== @data;
Leftward pipes are a convenient way of explicitly indicating the typical
right-to-left flow of data through a chain of operations:
@@ -844,31 +861,6 @@
Since the pipe iterator is bound into the final variable, the variable
can be just as lazy as the pipe that is producing the values.
-=begin Damian
-
-[DMC: On the other hand, these "push" semantics will break a very common
- left-to-right processing pattern:
-
- @data ==> grep { condition } ==> sort ==> @data;
-
- It will also impose a very subtle distinction between the broken
- symmetry of:
-
- @data = sort <== grep { condition } <== @data;
-
- and (the much more tempting, but almost certainly wrong):
-
- @data <== sort <== grep { condition } <== @data;
-
- Seems to me that we might be setting a trap here.
-
- Could there be a special case that turns off "push" semantics in
- any piped sequence where the origin is the same variable as the
- destination???
-]
-
-=end Damian
-
Because pipes are bound to arrays with "push" semantics, you can have
a receiver for multiple pipes:
@@ -947,15 +939,17 @@
use C<each()> instead:
(0..2; 'a'..'c') ==> my @;tmp;
- for @;tmp.map { say }
+ for @;tmp.each { say }
and then you just get 0,'a',1,'b',2,'c'. This is good for
- for @;tmp.map -> $i, $a { say "$i: $a" }
+ for @;tmp.each -> $i, $a { say "$i: $a" }
In list context the C<@;foo> notation is really a shorthand for C<[;](@;foo)>.
+In particular, you can use C<@;foo> to interpolate a multidimensional slice
+in an array or hash subscript.
-Every lexical scope gets its own implicitly declared C<@;> variable,
+Every lexical scope gets its own implicitly declared C<@;_> variable,
which is the default receiver. So instead of using C<@;foo> above
you can just say
@@ -964,9 +958,9 @@
pidigits() ==> ;
# outputs "(0, 'a', 3)\n"...
- for zip(@;) { .perl.say }
+ for zip(@;_) { .perl.say }
-If C<@;> is currently empty, then C<for zip(@;) {...}> would act on a
+If C<@;_> is currently empty, then C<for zip(@;_) {...}> would act on a
zero-dimensional slice (i.e. C<for (zip) {...}>), and output nothing
at all.
@@ -976,13 +970,13 @@
So
('a'...; 0...) ==> ;
- for zip(@; <== @foo) -> [$a, $i, $x] { ...}
+ for zip(@;_ <== @foo) -> [$a, $i, $x] { ...}
is the same as
'a'... ==> ;
0... ==> ;
- for zip(@; <== @foo) -> [$a, $i, $x] { ...}
+ for zip(@;_ <== @foo) -> [$a, $i, $x] { ...}
which is the same as
@@ -992,12 +986,12 @@
@foo ==> ;
0... ==> ;
- for each(@;) -> $x, $i { ...}
+ for each(@;_) -> $x, $i { ...}
is the same as
0... ==> ;
- for each(@foo; @;) -> $x, $i { ...}
+ for each(@foo; @;_) -> $x, $i { ...}
which is the same as
@@ -1006,13 +1000,19 @@
Note that the each method is also sensitive to multislicing, so you
could also just write that as:
- (@foo; 0...).map: -> $x, $i { ...}
+ (@foo; 0...).each: -> $x, $i { ...}
Also note that these come out to identical for ordinary arrays:
- @foo.map
+ @foo.each
@foo.cat
+The C<@;($foo)> coercer can be used to pull a multidim out of some
+object that contain one, such as a C<Capture> or C<Match> object. Like
+C<@()>, C<@;()> defaults to C<@;($/)>, and returns a multidimensional
+view of any match that repeatedly applies itself with C<:g> and
+the like. In contrast, C<@()> would flatten those into one list.
+
=head2 Closure parameters
Parameters declared with the C<&> sigil take blocks, closures, or
