Merge pull request #22 from krupan/grammar-fixes

Grammar fixes

Author: lotabout

tutorial/en/4-Top-down-Parsing.md

@@ -1,20 +1,20 @@
 In this chapter we will build a simple calculator using the top-down parsing
 technique. This is the preparation before we start to implement the parser.
 
-I will introduce a small set of theories but not gurantee to be absolute
+I will introduce a small set of theories but will not gurantee to be absolutely
 correct, please consult your textbook if you have any confusion.
 
 ## Top-down parsing
 
-Traditionally, we have top-down parsing and bottom-up parsing. Top-down method
-will start with a non-terminator and recursively check the source code to
+Traditionally, we have top-down parsing and bottom-up parsing. The top-down
+method will start with a non-terminator and recursively check the source code to
 replace the non-terminators with its alternatives until no non-terminator is
 left.
 
 You see I used the top-down method for explaining "top-down" because you'll
-have to know what a "non-terminator" is to understand the above graph. But I
-havn't tell you what that is. We will tell in the next section. For now,
-consider "top-down" is try to tear down a big object into small pieces.
+have to know what a "non-terminator" is to understand the above paragraph. But I
+havn't told you what that is. We will explain in the next section. For now,
+consider "top-down" is trying to tear down a big object into small pieces.
 
 On the other hand "bottom-up" parsing is trying to combine small objects into
 a big one. It is often used in automation tools that generate parsers.
@@ -39,17 +39,17 @@ arithmetic calulater in BNF will be:
            | Num
 ```
 
-The one enbraced by `<>` is called a `Non-terminator`. They got the name
-because we can replace them with the ones on the right hand of `::=`.
+The item enclosed by `<>` is called a `Non-terminator`. They got the name
+because we can replace them with the items on the right hand of `::=`.
 `|` means alternative that means you can replace `<term>` with any one of
 `<term> * <factor>`, `<term> / <factor>` or `<factor>`. Those do not appear on
 the left side of `::=` is called `Terminator` such as `+`, `(`, `Num`, etc.
-They often corresponds to the tokens we got from lexer.
+They often corresponds to the tokens we got from the lexer.
 
 ## Top-down Example for Simple Calculator
 
-Parse tree is the inner structure we got after the parser consumes all the
-tokens and finish all the parsing. Let's take `3 * (4 + 2)` as an example to
+The parse tree is the inner structure we get after the parser consumes all the
+tokens and finishes all the parsing. Let's take `3 * (4 + 2)` as an example to
 show the connections between BNF grammer, parse tree and top-down parsing.
 
 Top-down parsing starts from a starting non-terminator which is `<term>` in
@@ -71,8 +71,8 @@ non-terminator we encountered.
 ```
 
 You can see that each step we replace a non-terminator using one of its
-alternatives(top-down) Until all of the sub-items are replaced to
-terminators(bottom). Some non-terminators are used recursively such as
+alternatives (top-down) Until all of the sub-items are replaced by
+terminators (bottom). Some non-terminators are used recursively such as
 `<expr>`.
 
 ## Advantages of Top-down Parsing
@@ -110,7 +110,7 @@ As you can see, function `expr` will never exit! In the grammar,
 non-terminator `<expr>` is used recursively and appears immediately after
 `::=` which causes left-recursion.
 
-Lucily, most left-recursive grammers(maybe all? I don't remember) can be
+Lucily, most left-recursive grammers (maybe all? I don't remember) can be
 properly transformed into non left-recursive equivalent ones. Our grammar for
 calculator can be converted into:
 
@@ -254,7 +254,7 @@ int main(int argc, char *argv[])
 
 You can play with your own calculator now. Or try to add some more functions
 based on what we've learned in the previous chapter. Such as variable support
-so that user can define variable to store values.
+so that a user can define variables to store values.
 
 ## Summary
 

tutorial/en/5-Variables.md

@@ -1,7 +1,7 @@
 In this chapter we are going to use EBNF to describe the grammer of our C
-interpreter, and add the support of variable.
+interpreter, and add the support of variables.
 
-Parser is more complicated than lexer, thus we will split it into 3 parts:
+The parser is more complicated than the lexer, thus we will split it into 3 parts:
 variables, functions and expressions.
 
 ## EBNF grammar
@@ -11,7 +11,7 @@ We've talked about BNF in the previous chapter,
 Extended-BNF. If you are familiar with regular expression, you should feel
 right at home. Personally I think it is more powerful and straightforward than
 BNF. Here is the EBNF grammar of our C interpreter, feel free to skip it if
-you feel too hard to understand.
+you feel it's too hard to understand.
 
 ```
 program ::= {global_declaration}+
@@ -61,15 +61,15 @@ void program() {
 ```
 
 I know that we havn't defined `global_declaration`, sometimes we need wishful
-thinking that maybe someone(say Bob) will implement that for you. So you can
+thinking that maybe someone (say Bob) will implement that for you. So you can
 focus on the big picture at first instead of drill down into all the details.
 That's the essence of top-down thinking.
 
 ## global_declaration()
 
-Now it is our duty(not Bob's) to implement `global_declaration`. It will try
-to parse variable definition, type definition(only enum is supported) and
-function definition:
+Now it is our duty (not Bob's) to implement `global_declaration`. It will try
+to parse variable definitions, type definitions (only enum is supported) and
+function definitions:
 
 ```c
 int basetype;    // the type of a declaration, make it global for convenience

tutorial/en/6-Functions.md

@@ -43,14 +43,14 @@ if (token == '(') {
 ...
 ```
 
-The type for current identifier(i.e. function name) had already been set
-correctly. The above chunk of code set the type(i.e. `Fun`) and the
+The type for current identifier (i.e. function name) had already been set
+correctly. The above chunk of code set the type (i.e. `Fun`) and the
 address in `text segment` for the function. Here comes `parameter_decl` and
 `body_decl`.
 
 ## Parameters and Assembly Output
 
-Before we get our hand dirty, we have to understand the assembly code that
+Before we get our hands dirty, we have to understand the assembly code that
 will be output for a function. Consider the following:
 
 ```c
@@ -62,8 +62,8 @@ int demo(int param_a, int *param_b) {
 }
 ```
 
-When `demo` is called, its calling frame(states of stack) will look like the
-following(please refer the the VM of chapter 2):
+When `demo` is called, its calling frame (states of stack) will look like the
+following (please refer to the VM of chapter 2):
 
 ```
 |    ....       | high address
@@ -83,7 +83,7 @@ following(please refer the the VM of chapter 2):
 |    ....       |  low address
 ```
 
-The key point here is no matter it is parameter(e.g. `param_a`) or local
+The key point here is no matter if it is a parameter (e.g. `param_a`) or local
 variable (e.g. `local_1`), they are all store on **stack**. Thus they are
 referred to by pointer `new_bp` and relative shfitment, while global variables
 which are stored in `text segment` are refered to by direct address. So we