Author: lwall
Date: 2009-11-20 03:40:33 +0100 (Fri, 20 Nov 2009)
New Revision: 29134
Modified:
docs/Perl6/Spec/S02-bits.pod
docs/Perl6/Spec/S03-operators.pod
docs/Perl6/Spec/S04-control.pod
Log:
[S02,3,4] attempt to rename void context to sink context and see if it clogs
Modified: docs/Perl6/Spec/S02-bits.pod
===================================================================
--- docs/Perl6/Spec/S02-bits.pod 2009-11-19 21:58:32 UTC (rev 29133)
+++ docs/Perl6/Spec/S02-bits.pod 2009-11-20 02:40:33 UTC (rev 29134)
@@ -1105,21 +1105,21 @@
Since the construct is in the form of a type cast, the parens are required.
If that syntax is unappealing or you wish to run multiple statements
-in a block, it happens that the C<void> statement prefix also converts
+in a block, it happens that the C<sink> statement prefix also converts
any value to C<Nil>, so the examples above can be expressed
without parentheses:
- @inclist = map { $_ + 1 }, @list || void warn 'Empty @list!';
+ @inclist = map { $_ + 1 }, @list || sink warn 'Empty @list!';
- @inclist = do for @list || void { warn 'Empty @list!'; $warnings++; } {
+ @inclist = do for @list || sink { warn 'Empty @list!'; $warnings++; } {
$_ + 1;
}
- @inclist = do map { $_ + 1 }, @list or void warn 'Empty @list!';
+ @inclist = do map { $_ + 1 }, @list or sink warn 'Empty @list!';
@inclist = do for @list {
$_ + 1;
- } or void { warn 'Empty @list!'; $warnings++; }
+ } or sink { warn 'Empty @list!'; $warnings++; }
=head2 Immutable types
@@ -3805,7 +3805,7 @@
=item *
-Perl still has the three main contexts: void, item (scalar), and list.
+Perl still has the three main contexts: sink (void), item (scalar), and list.
=item *
Modified: docs/Perl6/Spec/S03-operators.pod
===================================================================
--- docs/Perl6/Spec/S03-operators.pod 2009-11-19 21:58:32 UTC (rev 29133)
+++ docs/Perl6/Spec/S03-operators.pod 2009-11-20 02:40:33 UTC (rev 29134)
@@ -2682,7 +2682,7 @@
$a = 1, 2, 3;
-because the 2 and 3 will be seen as being in a void context, as if
+because the 2 and 3 will be seen as being in a sink (void) context, as if
you'd said:
($a = 1), 2, 3;
Modified: docs/Perl6/Spec/S04-control.pod
===================================================================
--- docs/Perl6/Spec/S04-control.pod 2009-11-19 21:58:32 UTC (rev 29133)
+++ docs/Perl6/Spec/S04-control.pod 2009-11-20 02:40:33 UTC (rev 29134)
@@ -678,23 +678,23 @@
A variant of C<do> is C<gather>. Like C<do>, it is followed by a
statement or block, and executes it once. Unlike C<do>, it evaluates
-the statement or block in void context; its return value is instead
+the statement or block in sink (void) context; its return value is instead
specified by calling the C<take> list prefix operator one or more times
within the dynamic scope of the C<gather>. The C<take> function's
signature is like that of C<return>; it merely captures the C<Capture>
of its arguments without imposing any additional constraints (in the
absence of context propagation by the optimizer). The value returned
by the C<take> to its own context is that same C<Capture> object (which
-is ignored when the C<take> is in void context). Regardless of the
+is ignored when the C<take> is in sink context). Regardless of the
C<take>'s context, the C<Capture> object is also added to the list of
values being gathered, which is returned by the C<gather> in the form
of a lazy slice, with each slice element corresponding to one C<take>
capture. (A list of C<Capture>s is lazily flattened in normal list context,
but you may "unflatten" it again with a C<@@()> contextualizer.)
-Because C<gather> evaluates its block or statement in void context,
-this typically causes the C<take> function to be evaluated in void
-context. However, a C<take> function that is not in void context
+Because C<gather> evaluates its block or statement in sink context,
+this typically causes the C<take> function to be evaluated in sink
+context. However, a C<take> function that is not in sink context
gathers its arguments I<en passant> and also returns them unchanged.
This makes it easy to keep track of what you last "took":
@@ -727,8 +727,8 @@
# @@$c produces (1,10),(2,20) -- list of Captures, a 2-D list.
# $$c produces ((1,10),(2,20)) -- the saved Capture itself as one item in
item context.
-Note that the C<take> itself is in void context in this example because
-the C<for> loop is in void context.
+Note that the C<take> itself is in sink context in this example because
+the C<for> loop is in sink context.
A C<gather> is not considered a loop, but it is easy to combine with a loop
statement as in the examples above.
@@ -784,7 +784,7 @@
X<do>
Other similar forms, where a keyword is followed by code to be controlled by
it, may also take bare statements,
-including C<try>, C<quietly>, C<contend>, C<async>, C<lazy>, and C<void>.
These constructs
+including C<try>, C<quietly>, C<contend>, C<async>, C<lazy>, and C<sink>.
These constructs
establish a dynamic scope without necessarily establishing a lexical
scope. (You can always establish a lexical scope explicitly by using
the block form of argument.) As statement introducers, all these
@@ -1291,7 +1291,7 @@
Even in the absence of closure cloning, C<INIT> runs before the
mainline code, while C<START> puts off the initialization till the
last possible moment, then runs exactly once, and caches its value
-for all subsequent calls (assuming it wasn't called in void context,
+for all subsequent calls (assuming it wasn't called in sink context,
in which case the C<START> is evaluated once only for its side effects).
In particular, this means that C<START> can make use of any parameters
passed in on the first call, whereas C<INIT> cannot.
