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.