Minor updates and spell fixes for the compiler section

Author: orta

docs/compiler/ast-tip-children.md

@@ -23,7 +23,7 @@ export function forEachChild<T>(node: Node, cbNode: (node: Node) => T, cbNodeArr
             // .... lots more
 ```
 
-Basically it checks `node.kind` and based on that assumes an interface offered by the `node` and calls the `cbNode` on the children. Note however that this function doesn't call `visitNode` for *all* children (e.g. SyntaxKind.SemicolonToken). If you want *all* the children of a node in the AST just call `.getChildren` member function of the `Node`.
+Basically it checks `node.kind` and based on that assumes an interface offered by the `node` and calls the `cbNode` on the children. Note, however that this function doesn't call `visitNode` for *all* children (e.g. SyntaxKind.SemicolonToken). If you want *all* the children of a node in the AST just call `.getChildren` member function of the `Node`.
 
 E.g. here is a function that prints the verbose `AST` of a node:
 

docs/compiler/ast-tip-syntaxkind.md

@@ -10,7 +10,7 @@ export const enum SyntaxKind {
     // ... LOTS more
 ```
 
-It's a `const enum` (a concept [we covered previously](../enums.md)) so that it gets *inlined* (e.g. `ts.SyntaxKind.EndOfFileToken` becomes `1`) and we don't get a dereferencing cost when working with AST. However the compiler is compiled with `--preserveConstEnums` compiler flag so that the enum *is still available at runtime*. So in JavaScript you can use `ts.SyntaxKind.EndOfFileToken` if you want. Additionally you can convert these enum members to display strings using the following function:
+It's a `const enum` (a concept [we covered previously](../enums.md)) so that it gets *inlined* (e.g. `ts.SyntaxKind.EndOfFileToken` becomes `1`) and we don't get a dereferencing cost when working with the AST. However the compiler is compiled with `--preserveConstEnums` compiler flag so that the enum *is still available at runtime*. So in JavaScript you can use `ts.SyntaxKind.EndOfFileToken` if you want. Additionally you can convert these enum members to display strings using the following function:
 
 ```ts
 export function syntaxKindToName(kind: ts.SyntaxKind) {

docs/compiler/ast-trivia.md

@@ -1,19 +1,21 @@
 ### Trivia
-Trivia (called that because its `trivial`) represent the parts of the source text that are largely insignificant for normal understanding of the code, such as whitespace, comments, and even conflict markers. Trivia is *not stored* in the AST (to keep it lightweight). However it can be fetched *on demand* using a few `ts.` APIs. Before we show them you need to understand
+Trivia (called that because it's `trivial`) represent the parts of the source text that are largely insignificant for normal understanding of the code. For example; whitespace, comments, and even conflict markers. Trivia is *not stored* in the AST (to keep it lightweight). However it can be fetched *on demand* using a few `ts.*` APIs. 
+
+Before we show them you need to understand the following:
 
 #### Trivia Ownership
 In General:
 * A token owns any trivia after it on the *same* line *upto* the next token.
 * Any comment *after that line* is associated with the following token.
 
 For leading and ending comments in a file:
-* The first token in the source file gets all the initial trivia
+* The first token in the source file gets all the initial trivia.
 * The last sequence of trivia in the file is tacked onto the end-of-file token, which otherwise has zero width.
 
 The first token in the source file gets all the initial trivia, and the last sequence of trivia in the file is tacked onto the end-of-file token, which otherwise has zero width.
 
 #### Trivia APIs
-For most basic uses, comments are the "interesting" trivia. The comments that belong to a Node which can be fetched through the following functions:
+For most basic uses, comments are the "interesting" trivia. The comments that belong to a Node can be fetched through the following functions:
 
 Function | Description
 ---------|------------

docs/compiler/ast.md

@@ -1,13 +1,13 @@
 ## Node
-The basic building block of the Abstract Syntax Tree (AST). In general node represent non-terminals in the language grammar; some terminals are kept in the tree such as identifiers and literals.
+The basic building block of the Abstract Syntax Tree (AST). In general a `Node` represents non-terminals in the language grammar; however, some terminals are kept in the tree such as identifiers and literals.
 
-Two key things make up an AST node documentation. Its `SyntaxKind` which identifies it within the AST and its `interface`, the API the node provides  when instantiated for the AST.
+Two key things make up an AST node's documentation. The node's `SyntaxKind` which identifies its type within the AST, and its `interface`, the API the node provides when instantiated into the AST.
 
 Here are a few key `interface Node` members:
 * `TextRange` members that identify the node's `start` and `end` in the source file.
 * `parent?: Node` the parent of the node in the AST.
 
-There are other additional members for node flags and modifiers etc. that you can lookup by searching `interface Node` in the source code but the ones we mentioned are vital for node traversal.
+There are other additional members for `Node` flags and modifiers etc. that you can lookup by searching `interface Node` in the source code but the ones we mentioned are vital for node traversal.
 
 ## SourceFile
 

docs/compiler/binder-container.md

@@ -120,4 +120,4 @@ function bindChildren(node: Node) {
 }
 ```
 
-As you might recall from section on binder functions : `bindChildren` is called from the `bind` function. So we have the recursive bindig setup : `bind` calls `bindChildren` calls `bind` for each child.
+As you might recall from section on binder functions : `bindChildren` is called from the `bind` function. So we have the recursive binding setup : `bind` calls `bindChildren` calls `bind` for each child.

docs/compiler/binder-declarations.md

@@ -29,8 +29,8 @@ function addDeclarationToSymbol(symbol: Symbol, node: Declaration, symbolFlags:
 ```
 
 The important linking portions:
-* creates a link to the Symbol from the AST node (`node.symbol`).
-* add the node as *one of* the declarations of the Symbol (`symbol.declarations`).
+* Creates a link to the Symbol from the AST node (`node.symbol`).
+* Adds the node as *one of* the declarations of the Symbol (`symbol.declarations`).
 
 #### Declaration
 Declaration is just a `node` with an optional name. In `types.ts`

docs/compiler/binder-symbolflags.md

@@ -1,5 +1,72 @@
 ### SymbolFlags
-Symbols have `SymbolFlags`. Below we eplain the meaning of the important ones
+Symbols have `SymbolFlags`. Below we have them in their verbatim, as of TypeScript 2.2
+
+```ts
+const enum SymbolFlags {
+      None = 0,
+      FunctionScopedVariable = 1,
+      BlockScopedVariable = 2,
+      Property = 4,
+      EnumMember = 8,
+      Function = 16,
+      Class = 32,
+      Interface = 64,
+      ConstEnum = 128,
+      RegularEnum = 256,
+      ValueModule = 512,
+      NamespaceModule = 1024,
+      TypeLiteral = 2048,
+      ObjectLiteral = 4096,
+      Method = 8192,
+      Constructor = 16384,
+      GetAccessor = 32768,
+      SetAccessor = 65536,
+      Signature = 131072,
+      TypeParameter = 262144,
+      TypeAlias = 524288,
+      ExportValue = 1048576,
+      ExportType = 2097152,
+      ExportNamespace = 4194304,
+      Alias = 8388608,
+      Prototype = 16777216,
+      ExportStar = 33554432,
+      Optional = 67108864,
+      Transient = 134217728,
+      Enum = 384,
+      Variable = 3,
+      Value = 107455,
+      Type = 793064,
+      Namespace = 1920,
+      Module = 1536,
+      Accessor = 98304,
+      FunctionScopedVariableExcludes = 107454,
+      BlockScopedVariableExcludes = 107455,
+      ParameterExcludes = 107455,
+      PropertyExcludes = 0,
+      EnumMemberExcludes = 900095,
+      FunctionExcludes = 106927,
+      ClassExcludes = 899519,
+      InterfaceExcludes = 792968,
+      RegularEnumExcludes = 899327,
+      ConstEnumExcludes = 899967,
+      ValueModuleExcludes = 106639,
+      NamespaceModuleExcludes = 0,
+      MethodExcludes = 99263,
+      GetAccessorExcludes = 41919,
+      SetAccessorExcludes = 74687,
+      TypeParameterExcludes = 530920,
+      TypeAliasExcludes = 793064,
+      AliasExcludes = 8388608,
+      ModuleMember = 8914931,
+      ExportHasLocal = 944,
+      HasExports = 1952,
+      HasMembers = 6240,
+      BlockScoped = 418,
+      PropertyOrAccessor = 98308,
+      Export = 7340032,
+      ClassMember = 106500,
+  }
+  ```
 
 #### ValueModule
 `ValueModule // Instantiated module` is the SymbolFlag used for `SourceFile` if it an external module.

docs/compiler/binder-symboltable.md

@@ -1,14 +1,14 @@
 ### SymbolTable
 
-Its implemented as a simple HashMap. Here is the interface (`types.ts`):
+SymbolTable is implemented as a simple HashMap. Here is the interface (`types.ts`):
 
 ```ts
 interface SymbolTable {
     [index: string]: Symbol;
 }
 ```
 
-SymbolTables as initialized by binding. There are a few SymbolTables used by the compiler.
+SymbolTables are initialized by binding. There are a few SymbolTables used by the compiler:
 
 On `Node`:
 ```ts
@@ -25,7 +25,7 @@ exports?: SymbolTable;                  // Module exports
 Note: We saw `locals` getting initialized (to `{}`) by `bindChildren` based on `ContainerFlags`.
 
 #### SymbolTable population
-SymbolTable are populated with `Symbols` primarily by a call to `declareSymbol`. This function is presented below in entirety:
+SymbolTables are populated with `Symbols` primarily by a call to `declareSymbol`. This function is presented below in entirety:
 
 ```ts
 /**
@@ -100,7 +100,7 @@ function declareSymbol(symbolTable: SymbolTable, parent: Symbol, node: Declarati
 }
 ```
 
-Which SymbolTable gets populated is driven by the first argument to this function. e.g. when adding a declaration to a *container* of kind `SyntaxKind.ClassDeclaration` or `SytanxKind.ClassExpression` the function `declareClassMember` will get called which has the following code:
+Which SymbolTable is populated is driven by the first argument to this function. e.g. when adding a declaration to a *container* of kind `SyntaxKind.ClassDeclaration` or `SytanxKind.ClassExpression` the function `declareClassMember` will get called which has the following code:
 
 ```ts
 function declareClassMember(node: Declaration, symbolFlags: SymbolFlags, symbolExcludes: SymbolFlags) {

docs/compiler/binder.md

@@ -1,5 +1,5 @@
 ## Binder
-Most JavaScript transpilers out there are simpler than TypeScript in that they provide little in the way of code analysis. The typical JavaScript transpilers only have the following flow:
+Most JavaScript transpilers out there are simpler than TypeScript because they provide little in the way of code analysis. The typical JavaScript transpilers only have the following flow:
 
 ```ts
 SourceCode ~~Scanner~~> Tokens ~~Parser~~> AST ~~Emitter~~> JavaScript
@@ -8,7 +8,7 @@ SourceCode ~~Scanner~~> Tokens ~~Parser~~> AST ~~Emitter~~> JavaScript
 While the above architecture is true as a simplified understand of TypeScript js generation, a key feature of TypeScript is its *Semantic* system. In order to assist type checking (performed by `checker`), the `binder` (in `binder.ts`) is used to connect the various parts of the source code into a coherent type system that can then be used by the `checker`. The main responsibility of the binder is to create the _Symbols_.
 
 ### Symbol
-Symbols connect declaration nodes in the AST to other declarations contributing to the same entity. Symbols are the basic building block of the Semantic system. The symbol constructor is defined in `core.ts` (and `binder` actually uses the `objectAllocator.getSymbolConstructor` to get its hands on it). Here is the contructor:
+Symbols connect declaration nodes in the AST to other declarations contributing to the same entity. Symbols are the basic building block of the Semantic system. The symbol constructor is defined in `core.ts` (and `binder` actually uses the `objectAllocator.getSymbolConstructor` to get its hands on it). Here is the constructor:
 
 ```ts
 function Symbol(flags: SymbolFlags, name: string) {

docs/compiler/checker-global.md

@@ -1,5 +1,5 @@
 ### Global Namespace Merging
-Within `initializeTypeChecker` the following code exists :
+Within `initializeTypeChecker` the following code exists:
 
 ```ts
 // Initialize global symbol table

docs/compiler/checker.md

@@ -1,5 +1,5 @@
 ## Checker
-Like we mentioned before *checker* is the thing that makes TypeScript uniquely more powerful than *just another JavaScript transpiler*. The checker is located in `checker.ts` and at this moment it is 15k+ lines of code (largest part of the compiler).
+Like we mentioned before *checker* is the thing that makes TypeScript uniquely more powerful than *just another JavaScript transpiler*. The checker is located in `checker.ts` and at this moment it is 23k+ lines of TypeScript (largest part of the compiler).
 
 ### Usage by Program
 The `checker` is initialized by `program`. The following is a sampling of the call stack (we showed the same one when looking at `binder`):

docs/compiler/emitter-functions.md

@@ -5,7 +5,7 @@ Defined in `emitter.ts` here is the function signature:
 export function emitFiles(resolver: EmitResolver, host: EmitHost, targetSourceFile?: SourceFile): EmitResult {
 ```
 
-`EmitHost` is a just a simplified (as in narrowed down) version of `CompilerHost` (and is at runtime actually a CompilerHost for many use cases).
+`EmitHost` is a just a simplified (as in narrowed down) version of `CompilerHost` (and is at runtime actually a `CompilerHost` for many use cases).
 
 The most interesting call stack from `emitFiles` is the following:
 

docs/compiler/emitter-sourcemaps.md

@@ -1,6 +1,6 @@
 ### Emitter SourceMaps
 
-We said that the bulk of the `emitter.ts` is the local function `emitJavaScript` (we showed the initialization routine of this function before). It basically sets up a bunch of locals and hits off to `emitSourceFile`. The following is a revisiting of the function, this time focusing on SourceMap stuff:
+We said that the bulk of the `emitter.ts` is the local function `emitJavaScript` (we showed the initialization routine of this function before). It basically sets up a bunch of locals and hits off to `emitSourceFile`. The following is a revisiting of the function, this time focusing on `SourceMap` stuff:
 
 ```ts
 function emitJavaScript(jsFilePath: string, root?: SourceFile) {
@@ -63,7 +63,7 @@ function emitJavaScript(jsFilePath: string, root?: SourceFile) {
     /// BUNCH OF LOCAL FUNCTIONS
 ```
 
-The imporant function call here : `initializeEmitterWithSourceMaps` which is a function local to `emitJavaScript` that overrides some locals that were already defined here. At the bottom of `initializeEmitterWithSourceMaps` you will notice the overriding:
+The important function call here : `initializeEmitterWithSourceMaps` which is a function local to `emitJavaScript` that overrides some locals that were already defined here. At the bottom of `initializeEmitterWithSourceMaps` you will notice the overriding:
 
 ```ts
     // end of `initializeEmitterWithSourceMaps`
@@ -78,4 +78,4 @@ The imporant function call here : `initializeEmitterWithSourceMaps` which is a f
     writeComment = writeCommentRangeWithMap;
 ```
 
-This means that the bulk of emitter code can not care about SourceMap and just use these local functions the same way with or without SourceMaps.
+This means that the bulk of emitter code can not care about `SourceMap` and just use these local functions the same way with or without SourceMaps.

docs/compiler/overview.md

@@ -10,8 +10,8 @@ It is split into the follow key parts:
 
 Each of these get their own unique files in the source. These parts will be explained later on in this chapter.
 
-## NTypeScript
-We have a project called [NTypeScript](https://github.com/TypeStrong/ntypescript) which makes it easier to play around with the compiler API e.g. by exposing internal APIs. You use it the same way you would use `typescript` but just have an `n` prefix for all things (binary : `ntsc`, require: `ntypescript`). This is also the compiler used by atom-typescript and the one we will use to present these examples.
+## BYOTS
+We have a project called [Bring Your Own TypeScript (BYOTS)](https://github.com/basarat/byots) which makes it easier to play around with the compiler API e.g. by exposing internal APIs. You can use it to expose your local app's version of TypeScript globally.
 
 ## Syntax vs. Semantics
 Just because something is *syntactically* correct doesn't mean it is *semantically* correct. Consider the following piece of TypeScript code which although *syntactically* valid is *semantically* wrong

docs/compiler/scanner.md

@@ -1,5 +1,5 @@
 ## Scanner
-The sourcecode for the TypeScript scanner is located entirely in `scanner.ts`. Scanner is *controlled* internally by the `Parser` to convert the source code to an AST. Here is what the desired outcome is.
+The source code for the TypeScript scanner is located entirely in `scanner.ts`. Scanner is *controlled* internally by the `Parser` to convert the source code to an AST. Here is what the desired outcome is.
 
 ```
 SourceCode ~~ scanner ~~> Token Stream ~~ parser ~~> AST