Author: bernhard Date: Mon Dec 29 08:24:00 2008 New Revision: 34582 Modified: trunk/CREDITS trunk/docs/book/ch03_pir_basics.pod trunk/docs/book/ch04_pir_subroutines.pod trunk/docs/book/ch05_pasm.pod trunk/docs/book/ch09_pct.pod trunk/docs/book/ch10_hlls.pod trunk/docs/book/ch12_opcodes.pod
Log: RT #61786: [PATCH] docs/book typo corrections Courtesy of Ovid. Modified: trunk/CREDITS ============================================================================== --- trunk/CREDITS (original) +++ trunk/CREDITS Mon Dec 29 08:24:00 2008 @@ -252,6 +252,11 @@ D: Rakudo builtins E: [email protected] +N: Curtis 'Ovid' Poe +U: Ovid +D: docs/test cleanups/Makefile fixes +E: [email protected] + N: Curtis Rawls U: cgrawls D: imcc optimizer and register allocator patches and tests Modified: trunk/docs/book/ch03_pir_basics.pod ============================================================================== --- trunk/docs/book/ch03_pir_basics.pod (original) +++ trunk/docs/book/ch03_pir_basics.pod Mon Dec 29 08:24:00 2008 @@ -27,7 +27,7 @@ instructional code examples. The documentation for the PIR compiler IMCC in F<docs/imcc/> or the project documentation in F<docs/> are good sources for information about the current syntax, semantics, and -implementation. The other PIR compiler, PIRC, has it's own documentation +implementation. The other PIR compiler, PIRC, has its own documentation that is slowly maturing. This is a useful source of information too. The test suite in F<t/compilers/imcc/> shows examples of proper working code. In fact, the test suite is the definitive PIR resource, because it shows how PIR @@ -268,7 +268,7 @@ The statement C<sum = $I42 + 5> translates to something like C<add I16, I17, 5> in PASM. The exact translation isn't too important N<Unless you're hacking on IMCC or PIRC!>, so we don't have to worry -about it for now. We will talk more about PASM and it's instruction +about it for now. We will talk more about PASM and its instruction set in X<CHP-5> Chapter 5. PIR also provides automatic assignment operators such as C<+=>, C<-=>, Modified: trunk/docs/book/ch04_pir_subroutines.pod ============================================================================== --- trunk/docs/book/ch04_pir_subroutines.pod (original) +++ trunk/docs/book/ch04_pir_subroutines.pod Mon Dec 29 08:24:00 2008 @@ -284,7 +284,7 @@ In this example, the subroutine C<add_two> makes two calls to c<add_one>. The second call to C<add_one> is used as the return -value. C<add_one> is called and it's result is immediately returned +value. C<add_one> is called and its result is immediately returned to the caller of C<add_two>, it is never stored anywhere. We can optimize this situation is we realize that the second call to C<add_one> is returning to the same place that C<add_two> is. The @@ -308,7 +308,7 @@ What this means is that we can define a subroutine by name inside a larger subroutine, and our "inner" subroutine is only visible and callable from the "outer" subroutine. Plus, the "inner" subroutine inherits all the -lexical variables from the outer subroutine, but is able to define it's +lexical variables from the outer subroutine, but is able to define its own lexical variables that cannot be seen or modified by the outer subroutine. =head3 Scope and HLLs Modified: trunk/docs/book/ch05_pasm.pod ============================================================================== --- trunk/docs/book/ch05_pasm.pod (original) +++ trunk/docs/book/ch05_pasm.pod Mon Dec 29 08:24:00 2008 @@ -66,7 +66,7 @@ capital letters to make them stand out from the rest of the source code more clearly. A label definition is simply the name of the label followed by a colon. It can be on its own line N<In fact, we recommend -that it be on it's own line, for readability.>: +that it be on its own line, for readability.>: LABEL: print "Norwegian Blue\n" Modified: trunk/docs/book/ch09_pct.pod ============================================================================== --- trunk/docs/book/ch09_pct.pod (original) +++ trunk/docs/book/ch09_pct.pod Mon Dec 29 08:24:00 2008 @@ -5,7 +5,7 @@ Z<CHP-8> So far we've talked a lot about low-level Parrot programming with -PIR and PASM. However, the true power of Parrot is it's ability to +PIR and PASM. However, the true power of Parrot is its ability to host programs written in high level languages such as Perl 6, Python, Ruby, Tcl, and PHP. In order to write code in these languages developers need there to be compilers that convert from the language @@ -185,7 +185,7 @@ A recursive descent parser, like the one used in PGE, is a top-down parser. This means it attempts to start at the highest-level rule and -work it's way down to the individual input tokens in order to match +work its way down to the individual input tokens in order to match the given input. Once the parser has matched the entire input N<a source code file, or a line of input at the terminal in interactive mode> the parse is considered successful and the generated AST is @@ -342,7 +342,7 @@ 'Skywalker' } -This is the same rule, except now it passes two arguments to it's +This is the same rule, except now it passes two arguments to its action method: the match object and the name of the person who got matched. @@ -371,7 +371,7 @@ Notice that an C<if_statement> can contain a list of C<statement>s, and that each statement may itself be an C<if_statement>? This is called I<recursion> X<Recursion>, and is part of where the "Recursive Descent" -algorithm gets it's name from. +algorithm gets its name from. Now, let's look at a more direct example of a comma-separated list of integer digits to form an array. We can define this recursively as @@ -450,7 +450,7 @@ equation are split into two subtypes: I<terms> and I<operators>. Operators themselves are split into a number of types including postfix (C<-a>), suffix (C<i++>), infix (C<x + y>), circumfix (C<[z]>), postcircumix -(C<a[b]>), and list (C<1, 2, 3>). Each operator gets it's own precidence +(C<a[b]>), and list (C<1, 2, 3>). Each operator gets its own precidence number that specifies how closely it binds to the terms. In the example above, the expression is parsed @@ -478,8 +478,8 @@ of saying that the rule is overridable dynamically, and that it might be defined somewhere else. In this case, PCT takes information from the proto declaration and fills in the details for us. On another note, this also means that the HLL -itself can modify it's own grammar at run time, by overriding the proto -definitions for it's operator table. Some languages call this process "operator +itself can modify its own grammar at run time, by overriding the proto +definitions for its operator table. Some languages call this process "operator overloading". A proto is defined like this, taking some of our grammar rules above: @@ -802,4 +802,4 @@ # Local variables: # c-file-style: "parrot" # End: -# vim: expandtab shiftwidth=4: \ No newline at end of file +# vim: expandtab shiftwidth=4: Modified: trunk/docs/book/ch10_hlls.pod ============================================================================== --- trunk/docs/book/ch10_hlls.pod (original) +++ trunk/docs/book/ch10_hlls.pod Mon Dec 29 08:24:00 2008 @@ -14,11 +14,11 @@ interoperating with each other then compiled languages have because compiled languages operate at the same machine-code level and typically can make use of the same application binary interface (ABI). With the -right compiler settings, programs written in Visual Basic and interoperate +right compiler settings, programs written in Visual Basic can interoperate with programs written in C N<On some systems anyway>, which can call -functions written in C++, in Ada, Fortran, and Pascal. To try to mix +functions written in C++, in Ada, Fortran, Pascal and so on. To try to mix two common dynamic languages, like Perl and Python, or Ruby and PHP, you -would need to custom write some kind of "glue" function to try to include +would need to write some kind of custom "glue" function to try to include an interpreter object from one language as a library for another language, and then write code to try and get the parser for one to interact nicely with the parser for the other. It's a nightmare, frankly, and you don't @@ -33,7 +33,7 @@ a binding for a popular library such as opengl or xlib once, and include that library into any language that needs it. Compare this to the current situation where a library like Gtk2 needs to have bindings for every -language that wants to use it.In short, Parrot should make interoperation +language that wants to use it. In short, Parrot should make interoperation easier for everybody. This chapter is going to talk about HLLs, the way they operate, and the @@ -122,7 +122,7 @@ the compiler fakecutables. The fakecutables contain a link to C<libparrot>, which contains all the necessary guts of Parrot. When the fakecutable is executed, a small driver program loads the PBC data into libparrot through -it's API functions. The Parrot executable is just one small example of how +its API functions. The Parrot executable is just one small example of how Parrot's functionality can be implemented, and we will talk about a few other ways here too. @@ -135,7 +135,7 @@ =head3 Creating and Interoperating Interpreters Parrot's executable, which is the interface which most users are going -to be familiar with uses a single interpreter structure to perform a +to be familiar with, uses a single interpreter structure to perform a single execution task. However, this isn't the only supported structural model that Parrot supports. In fact, the interpreter structure is not a singleton, and multiple interpreters can be created by a single program. @@ -160,7 +160,7 @@ specific environments (such as within a single program) are called I<Domain-Specific Languages> (DSL). DSLs are a very popular topic because a DSL allows developers to create a custom language that makes dealing -with a given problem space or data set very easy. Parrot and it's suite +with a given problem space or data set very easy. Parrot and its suite of compiler tools in turn make creating the DSLs very easy. It's all about ease of use. @@ -251,4 +251,4 @@ # Local variables: # c-file-style: "parrot" # End: -# vim: expandtab shiftwidth=4: \ No newline at end of file +# vim: expandtab shiftwidth=4: Modified: trunk/docs/book/ch12_opcodes.pod ============================================================================== --- trunk/docs/book/ch12_opcodes.pod (original) +++ trunk/docs/book/ch12_opcodes.pod Mon Dec 29 08:24:00 2008 @@ -76,7 +76,7 @@ The fast core is a bare-bones core that doesn't do any of the bounds-checking or context updating that the slow core does. The fast core is the way Parrot should run, and is used to find and debug places -where execution strays outside of it's normal bounds. In pseudocode, the +where execution strays outside of its normal bounds. In pseudocode, the fast core is very much like the slow core except it doesn't do the bounds checking between each instruction, and doesn't update the interpreter's current context for each dispatch. @@ -88,7 +88,7 @@ =item* Switch Core -As it's name implies, the switch core uses a gigantic C C<switch / case> +As its name implies, the switch core uses a gigantic C C<switch / case> structure to execute opcodes. Here's a brief example of how this architecture works: @@ -306,7 +306,7 @@ When Parrot parses through the file and sees the C<Foo> operation, it converts it to the real name C<Foo_i_n>. The real name of an opcode -is it's name followed by an underscore-separated ordered list of +is its name followed by an underscore-separated ordered list of the parameters to that opcode. This is how Parrot appears to use polymorphism: It translates the overloaded opcode common names into longer unique names depending on the parameter list of that opcode. Here @@ -322,7 +322,7 @@ This isn't a complete list, but you should get the picture. Each different combination of parameters translates to a different unique operation, and each operation is remarkably simple to implement. In some cases, Parrot -can even use it's multi-method dispatch system to call opcodes which are +can even use its multi-method dispatch system to call opcodes which are heavily overloaded, or for which there is no exact fit but the parameters could be coerced into different types to complete the operation. For instance, attempting to add a STRING to a PMC might coerce the string into
