diff options
Diffstat (limited to 'pod/perlhack.pod')
| -rw-r--r-- | pod/perlhack.pod | 42 |
1 files changed, 21 insertions, 21 deletions
diff --git a/pod/perlhack.pod b/pod/perlhack.pod index 83e16d13ae..dd55ca17ae 100644 --- a/pod/perlhack.pod +++ b/pod/perlhack.pod @@ -34,12 +34,12 @@ words, it's your usual mix of technical people. Over this group of porters presides Larry Wall. He has the final word in what does and does not change in the Perl language. Various -releases of Perl are shepherded by a ``pumpking'', a porter -responsible for gathering patches, deciding on a patch-by-patch +releases of Perl are shepherded by a "pumpking", a porter +responsible for gathering patches, deciding on a patch-by-patch, feature-by-feature basis what will and will not go into the release. For instance, Gurusamy Sarathy was the pumpking for the 5.6 release of Perl, and Jarkko Hietaniemi was the pumpking for the 5.8 release, and -Hugo van der Sanden and Rafael Garcia-Suarez share the pumpking for +Hugo van der Sanden and Rafael Garcia-Suarez share the pumpking crown for the 5.10 release. In addition, various people are pumpkings for different things. For @@ -130,7 +130,7 @@ Is this something that only the submitter wants added to the language, or would it be broadly useful? Sometimes, instead of adding a feature with a tight focus, the porters might decide to wait until someone implements the more generalized feature. For instance, instead of -implementing a ``delayed evaluation'' feature, the porters are waiting +implementing a "delayed evaluation" feature, the porters are waiting for a macro system that would permit delayed evaluation and much more. =item Does it potentially introduce new bugs? @@ -179,8 +179,8 @@ always a good idea. =item Is there another way to do it? -Larry said ``Although the Perl Slogan is I<There's More Than One Way -to Do It>, I hesitate to make 10 ways to do something''. This is a +Larry said "Although the Perl Slogan is I<There's More Than One Way +to Do It>, I hesitate to make 10 ways to do something". This is a tricky heuristic to navigate, though--one man's essential addition is another man's pointless cruft. @@ -194,16 +194,16 @@ authors, ... Perl is supposed to be easy. Working code is always preferred to pie-in-the-sky ideas. A patch to add a feature stands a much higher chance of making it to the language than does a random feature request, no matter how fervently argued the -request might be. This ties into ``Will it be useful?'', as the fact +request might be. This ties into "Will it be useful?", as the fact that someone took the time to make the patch demonstrates a strong desire for the feature. =back -If you're on the list, you might hear the word ``core'' bandied -around. It refers to the standard distribution. ``Hacking on the -core'' means you're changing the C source code to the Perl -interpreter. ``A core module'' is one that ships with Perl. +If you're on the list, you might hear the word "core" bandied +around. It refers to the standard distribution. "Hacking on the +core" means you're changing the C source code to the Perl +interpreter. "A core module" is one that ships with Perl. =head2 Keeping in sync @@ -254,7 +254,7 @@ to doing so: =item rsync'ing the source tree Presuming you are in the directory where your perl source resides -and you have rsync installed and available, you can `upgrade' to +and you have rsync installed and available, you can "upgrade" to the bleadperl using: # rsync -avz rsync://ftp.linux.activestate.com/perl-current/ . @@ -805,7 +805,7 @@ there's three things going on here. C<yyparse>, the parser, lives in F<perly.c>, although you're better off reading the original YACC input in F<perly.y>. (Yes, Virginia, there B<is> a YACC grammar for Perl!) The job of the parser is to take your -code and `understand' it, splitting it into sentences, deciding which +code and "understand" it, splitting it into sentences, deciding which operands go with which operators and so on. The parser is nobly assisted by the lexer, which chunks up your input @@ -859,7 +859,7 @@ The C<PERL_ASYNC_CHECK> makes sure that things like signals interrupt execution if required. The actual functions called are known as PP code, and they're spread -between four files: F<pp_hot.c> contains the `hot' code, which is most +between four files: F<pp_hot.c> contains the "hot" code, which is most often used and highly optimized, F<pp_sys.c> contains all the system-specific functions, F<pp_ctl.c> contains the functions which implement control structures (C<if>, C<while> and the like) and F<pp.c> @@ -1254,10 +1254,10 @@ If you're not used to reading BNF grammars, this is how it works: You're fed certain things by the tokeniser, which generally end up in upper case. Here, C<ADDOP>, is provided when the tokeniser sees C<+> in your code. C<ASSIGNOP> is provided when C<=> is used for assigning. These are -`terminal symbols', because you can't get any simpler than them. +"terminal symbols", because you can't get any simpler than them. The grammar, lines one and three of the snippet above, tells you how to -build up more complex forms. These complex forms, `non-terminal symbols' +build up more complex forms. These complex forms, "non-terminal symbols" are generally placed in lower case. C<term> here is a non-terminal symbol, representing a single expression. @@ -1286,8 +1286,8 @@ call C<newBINOP> to create a new binary operator. The first parameter to C<newBINOP>, a function in F<op.c>, is the op type. It's an addition operator, so we want the type to be C<ADDOP>. We could specify this directly, but it's right there as the second token in the input, so we -use C<$2>. The second parameter is the op's flags: 0 means `nothing -special'. Then the things to add: the left and right hand side of our +use C<$2>. The second parameter is the op's flags: 0 means "nothing +special". Then the things to add: the left and right hand side of our expression, in scalar context. =head2 Stacks @@ -1335,14 +1335,14 @@ description of the macros used in stack manipulation. =item Mark stack -I say `your portion of the stack' above because PP code doesn't +I say "your portion of the stack" above because PP code doesn't necessarily get the whole stack to itself: if your function calls another function, you'll only want to expose the arguments aimed for the called function, and not (necessarily) let it get at your own data. The -way we do this is to have a `virtual' bottom-of-stack, exposed to each +way we do this is to have a "virtual" bottom-of-stack, exposed to each function. The mark stack keeps bookmarks to locations in the argument stack usable by each function. For instance, when dealing with a tied -variable, (internally, something with `P' magic) Perl has to call +variable, (internally, something with "P" magic) Perl has to call methods for accesses to the tied variables. However, we need to separate the arguments exposed to the method to the argument exposed to the original function - the store or fetch or whatever it may be. Here's how |