develooper Front page | perl.perl6.language | Postings from July 2006

[patch] typos in S04

From:
Agent Zhang
Date:
July 26, 2006 09:53
Subject:
[patch] typos in S04
Message ID:
c711ff240607260953k99ea7a0h49f38a1f02f6cdf6@mail.gmail.com
This is a patch for S04. Special thanks go to cjeris++ and other kind
persons on #perl6 for reviewing this.

Cheers,
Agent

Index: D:/projects/Perl6-Syn/S04.pod

===================================================================

--- D:/projects/Perl6-Syn/S04.pod	(revision 10479)

+++ D:/projects/Perl6-Syn/S04.pod	(working copy)

@@ -23,7 +23,7 @@


 Every block is a closure.  (That is, in the abstract, they're all
 anonymous subroutines that take a snapshot of their lexical scope.)
-How any block is invoked and how its results are used is a matter of
+How a block is invoked and how its results are used are matters of
 context, but closures all work the same on the inside.

 Blocks are delimited by curlies, or by the beginning and end of the
@@ -41,7 +41,7 @@


 A bare closure without placeholder arguments that uses C<$_>
 (either explicitly or implicitly) is treated as though C<$_> were a
-a formal parameter:
+formal parameter:

     $func = { print if $_ };   # Same as: $func = -> $_ { print if $_ };
     $func("printme");
@@ -473,7 +473,7 @@

 cases.)  Here "abnormal" means any transfer of control outward that
 is not just falling off the end of a block.  A C<return>,
 for example, is considered a form of abnormal control flow, since it
-can jump out of multiple levels of closure to the end of the scope
+can jump out of multiple levels of closures to the end of the scope
 of the current subroutine definition.  Loop commands like C<next>
 are abnormal, but looping because you hit the end of the block is not.
 The implicit break of a C<when> block is abnormal.
@@ -507,7 +507,7 @@


     leave <== :foo:bar:baz(1) if $leaving;

-or going the other way::
+or going the other way:

     $leaving and :foo:bar:baz(1) ==> leave;

@@ -521,7 +521,7 @@

 scope of that loop, and if that call mentions the outer loop's label,
 then that outer loop is the one that must be controlled. (This search
 of lexical scopes is limited to the current "official" subroutine.)
-If there is no such lexically scoped outer loop in current subroutine.
+If there is no such lexically scoped outer loop in the current subroutine.
 Then a fallback search is made outward through the dynamic scopes in
 the same way Perl 5 does.  (The difference between Perl 5 and Perl 6
 in this respect arises only because Perl 5 didn't have user-defined
@@ -568,7 +568,7 @@

 of parameters.  (Initialization of ordinary variables does not
 count--presumably the presence of a label will prevent code-movement
 optimizations past the label.)  So, for instance, it's always possible
-to goto into the next case of a C<when> or into either the "then"
+to C<goto> into the next case of a C<when> or into either the "then"
 or "else" branch of a conditional.  You may not go into a C<given>
 or a C<for>, though, because that would bypass a formal parameter
 binding (not to mention list generation in the case of C<for>).
@@ -580,7 +580,7 @@


 As in Perl 5, many built-in functions simply return undef when you ask
 for a value out of range, or the function fails somehow.  Perl 6 has
-C<Failure> objects, which refers to an unthrown C<Exception> object in
+C<Failure> objects, any of which refers to an unthrown C<Exception> object in
 C<$!> and knows whether it has been handled or not.

 If you test a C<Failure> for C<.valid>, C<.defined> or C<.true>, it causes
@@ -594,7 +594,7 @@

 default argument.

 At scope exit, C<$!> discards all handled exceptions from itself, then performs
-a GC check for all remaining (unhandled) exceptions.  If all of them are still
+a GC (Garbage Collection) check for all remaining (unhandled)
exceptions.  If all of them are still
 alive (e.g. by becoming part of the return value), then they are appended to
 C<< CALLER::<$!> >>.  Otherwise, it calls C<die> to throw those exceptions
 as a single new exception, which may then be caught with a C<CATCH> block in
@@ -672,13 +672,13 @@


 All of these trait blocks can see any previously declared lexical
 variables, even if those variables have not been elaborated yet when
-the closure is invoked.  (In which case the variables evaluate to an
-undefined value.)
+the closure is invoked (in which case the variables evaluate to an
+undefined value).

 Note: Apocalypse 4 confused the notions of C<PRE>/C<POST> with
C<ENTER>/C<LEAVE>.
 These are now separate notions.  C<ENTER> and C<LEAVE> are used only for
 their side effects.  C<PRE> and C<POST> must return boolean values that are
-evaluated according to the usual Design by Contract rules.  (Plus,
+evaluated according to the usual Design by Contract (DBC) rules.  (Plus,
 if you use C<ENTER>/C<LEAVE> in a class block, they only execute when the
 class block is executed, but C<PRE>/C<POST> in a class block are evaluated
 around every method in the class.)
@@ -718,7 +718,7 @@

 opening brace.  You I<must> parenthesize the expression if there is
 a bare block or pointy block that would be misinterpreted as the statement's
 block.  This is regardless of whether a term or operator is expected where
-the block occurs.  (A block inside brackets, or used as as
+the block occurs.  (A block inside brackets, or used as a
 postcircumfix is fine, though.)  Any block with whitespace
 in front of it will be taken as terminating the conditional, even if
 the conditional expression could take another argument.  Therefore
@@ -811,7 +811,7 @@

     $x =  do { given $foo { when 1 {2} when 3 {4} }} + $bar;
     $x = try { given $foo { when 1 {2} when 3 {4} }} + $bar;

-Just because there's a C<< statement_control:<BEGIN> >> does not
preclude us from
+The existence of a C<< statement_control:<BEGIN> >> does not preclude us from
 also defining a C<< prefix:<BEGIN> >> that I<can> be used within an expression:

     macro prefix:<BEGIN> (&beginblock) { beginblock().repr }
@@ -821,10 +821,10 @@

     $recompile_by = BEGIN { time } + $expiration_time;

 But C<< statement_control:<BEGIN> >> hides C<< prefix:<BEGIN> >> at
the start of a statement.
-You could also conceivably define a C<< prefix:<if> >>, but then you would
-get a syntax error when you say:
+You could also conceivably define a C<< prefix:<if> >>, but then you may not
+get what you want when you say:

-    print if $foo
+    print if $foo;

 since C<< prefix:<if> >> would hide C<< statement_modifier:<if> >>.

@@ -840,7 +840,7 @@


 Hypothetical variables are somewhat transactional--they keep their
 new values only on successful exit of the current block, and otherwise
-are rolled back to their original value.
+are rolled back to their original values.

 It is, of course, a failure to leave the block by propagating an error
 exception, though returning a defined value after catching an exception
@@ -880,7 +880,7 @@

 is free to turn unreferenced closures into mere blocks of code.
 It is also free to turn referenced closures into mere anonymous
 subroutines if the block does not refer to any external lexicals that
-could themselves be cloned.  In particular, named subroutines in any
+should themselves be cloned.  In particular, named subroutines in any
 scope do not consider themselves closures unless you take a reference
 to them.  So

@@ -899,10 +899,10 @@


 Some closures produce C<Code> objects at compile time that cannot be
 cloned, because they're not attached to any runtime code that can
-actively clone them.  C<BEGIN>, C<CHECK>, C<INIT>, and C<END> blocks
+actually clone them.  C<BEGIN>, C<CHECK>, C<INIT>, and C<END> blocks
 fall into this category.  Therefore you can't reliably refer to
-run-time variables from them even if they appear to be in scope.
-(The compile-time closure may, in fact, see a some kind of permanent
+run-time variables from these closures even if they appear to be in the scope.
+(The compile-time closure may, in fact, see some kind of permanent
 copy of the variable for some storage classes, but the variable is
 likely to be undefined when the closure is run in any case.)  It's
 only safe to refer to package variables and file-scoped lexicals from



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About