rltk 2.2.1 → 3.0.0

data/README.md

@@ -12,7 +12,7 @@ In addition, RLTK includes several ready-made lexers and parsers and a Turing-co
 
 ## Why Use RLTK
 
-Here are some reasons to use RLTK to build your lexers, parsers, and abstract syntax trees:
+Here are some reasons to use RLTK to build your lexers, parsers, and abstract syntax trees, as well as generating LLVM IR and native object files:
 
 * **Lexer and Parser Definitions in Ruby** - Many tools require you to write your lexer/parser definitions in their own format, which is then processed and used to generate Ruby code.  RLTK lexers/parsers are written entirely in Ruby and use syntax you are already familiar with.
 
@@ -34,6 +34,10 @@ Here are some reasons to use RLTK to build your lexers, parsers, and abstract sy
 
 * **Parse Tree Graphs** - RLTK parsers can print parse trees (in the DOT language) of accepted strings.
 
+* **LLVM Bindings** - RLTK provides wrappers for most of the C LLVM bindings.
+
+* **The Contractor** - LLVM's method of building instructions is a bit cumbersome, and is very imperative in style.  RLTK provides the Contractor class to make things easier.
+
 * **Documentation** - We have it!
 
 * **I Eat My Own Dog Food** - I'm using RLTK for my own projects so if there is a bug I'll most likely be the first one to know.
@@ -42,19 +46,21 @@ Here are some reasons to use RLTK to build your lexers, parsers, and abstract sy
 
 To create your own lexer using RLTK you simply need to subclass the {RLTK::Lexer} class and define the *rules* that will be used for matching text and generating tokens.  Here we see a simple lexer for a calculator:
 
-	class Calculator < RLTK::Lexer
-		rule(/\+/)	{ :PLS }
-		rule(/-/)	{ :SUB }
-		rule(/\*/)	{ :MUL }
-		rule(/\//)	{ :DIV }
+```Ruby
+class Calculator < RLTK::Lexer
+  rule(/\+/) { :PLS }
+  rule(/-/)  { :SUB }
+  rule(/\*/) { :MUL }
+  rule(/\//) { :DIV }
 
-		rule(/\(/)	{ :LPAREN }
-		rule(/\)/)	{ :RPAREN }
+  rule(/\(/) { :LPAREN }
+  rule(/\)/) { :RPAREN }
 
-		rule(/[0-9]+/)	{ |t| [:NUM, t.to_i] }
+  rule(/[0-9]+/) { |t| [:NUM, t.to_i] }
 
-		rule(/\s/)
-	end
+  rule(/\s/)
+end
+```
 
 The {RLTK::Lexer.rule} method's first argument is the regular expression used for matching text.  The block passed to the function is the action that executes when a substring is matched by the rule.  These blocks must return the *type* of the token (which must be in ALL CAPS; see the Parsers section), and optionally a *value*.  In the latter case you must return an array containing the *type* and *value*, which you can see an example of in the Calculator lexer shown above.  The values returned by the proc object are used to build a {RLTK::Token} object that includes the *type* and *value* information, as well as information about the line number the token was found on, the offset from the beginning of the line to the start of the token, and the length of the token's text.  If the *type* value returned by the proc is `nil` the input is discarded and no token is produced.
 
@@ -64,17 +70,19 @@ The {RLTK::Lexer} class provides both {RLTK::Lexer.lex} and {RLTK::Lexer.lex_fil
 
 The proc objects passed to the {RLTK::Lexer.rule} methods are evaluated inside an instance of the {RLTK::Lexer::Environment} class.  This gives you access to methods for manipulating the lexer's state and flags (see bellow).  You can also subclass the environment inside your lexer to provide additional functionality to your rule blocks.  When doing so you need to ensure that you name your new class Environment like in the following example:
 
-	class MyLexer < RLTK::Lexer
-		...
-		
-		class Environment < Environment
-			def helper_function
-				...
-			end
-			
-			...
-		end
-	end
+```Ruby
+class MyLexer < RLTK::Lexer
+  ...
+
+  class Environment < Environment
+    def helper_function
+      ...
+    end
+
+  ...
+  end
+end
+```
 
 ### Using States
 
@@ -89,16 +97,18 @@ The methods used to manipulate state are:
 
 States may be used to easily support nested comments.
 
-	class StateLexer < RLTK::Lexer
-		rule(/a/)		{ :A }
-		rule(/\s/)
-		
-		rule(/\(\*/)	{ push_state(:comment) }
-		
-		rule(/\(\*/, :comment)	{ push_state(:comment) }
-		rule(/\*\)/, :comment)	{ pop_state }
-		rule(/./,    :comment)
-	end
+```Ruby
+class StateLexer < RLTK::Lexer
+  rule(/a/) { :A }
+  rule(/\s/)
+
+  rule(/\(\*/) { push_state(:comment) }
+
+  rule(/\(\*/, :comment) { push_state(:comment) }
+  rule(/\*\)/, :comment) { pop_state            }
+  rule(/./,    :comment)
+end
+```
 
 By default the lexer will start in the `:default` state.  To change this, you may use the {RLTK::Lexer.start} method.
 
@@ -112,14 +122,16 @@ The lexing environment also maintains a set of *flags*.  This set is manipulated
 
 When *rules* are defined they may use a third parameter to specify a list of flags that must be set before the rule is considered when matching substrings.  An example of this usage follows:
 
-	class FlagLexer < RLTK::Lexer
-		rule(/a/)		{ set_flag(:a); :A }
-		
-		rule(/\s/)
-		
-		rule(/b/, :default, [:a])	{ set_flag(:b); :B }
-		rule(/c/, :default, [:a, :b])	{ :C }
-	end
+```Ruby
+class FlagLexer < RLTK::Lexer
+  rule(/a/) { set_flag(:a); :A }
+
+  rule(/\s/)
+
+  rule(/b/, :default, [:a])     { set_flag(:b); :B }
+  rule(/c/, :default, [:a, :b]) { :C               }
+end
+```
 
 ### Instantiating Lexers
 
@@ -129,16 +141,57 @@ In addition to using the {RLTK::Lexer.lex} class method you may also instantiate
 
 A RLTK::Lexer may be told to select either the first substring that is found to match a rule or the longest substring to match any rule.  The default behavior is to match the longest substring possible, but you can change this by using the {RLTK::Lexer.match_first} method inside your class definition as follows:
 
-	class MyLexer < RLTK::Lexer
-		match_first
-		
-		...
-	end
+```Ruby
+class MyLexer < RLTK::Lexer
+  match_first
+
+  ...
+end
+```
 
 ### Match Data
 
 Because it isn't RLTK's job to tell you how to write lexers and parsers, the MatchData object from a pattern match is available inside the Lexer::Environment object via the `match` accessor.
 
+## Context-Free Grammars
+
+The {RLTK::CFG} class provides an abstraction for context-free grammars.  For the purpose of this class terminal symbols appear in **ALL CAPS**, and non-terminal symbols appear in **all lowercase**.  Once a grammar is defined the {RLTK::CFG#first_set} and {RLTK::CFG#follow_set} methods can be used to find *first* and *follow* sets.
+
+### Defining Grammars
+
+A grammar is defined by first instantiating the {RLTK::CFG} class.  The {RLTK::CFG#production} and {RLTK::CFG#clause} methods may then be used to define the productions of the grammar.  The `production` method can take a Symbol denoting the left-hand side of the production and a string describing the right-hand side of the production, or the left-hand side symbol and a block.  In the first usage a single production is created.  In the second usage the block may contain repeated calls to the `clause` method, each call producing a new production with the same left-hand side but different right-hand sides.  {RLTK::CFG#clause} may not be called outside of {RLTK::CFG#production}.  Bellow we see a grammar definition that uses both methods:
+
+```Ruby
+grammar = RLTK::CFG.new
+
+grammar.production(:s) do
+  clause('A G D')
+  clause('A a C')
+  clause('B a D')
+  clause('B G C')
+end
+
+grammar.production(:a, 'b')
+grammar.production(:b, 'G')
+```
+
+### Extended Backus–Naur Form
+
+The RLTK::CFG class understands grammars written in the extended Backus–Naur form.  This allows you to use the \*, \+, and ? operators in your grammar definitions.  When each of these operators are encountered additional productions are generated.  For example, if the right-hand side of a production contained `NUM*` a production of the form `num_star -> | NUM num_star` is added to the grammar.  As such, your grammar should not contain productions with similar left-hand sides (e.g. foo_star, bar_question, or baz_plus).
+
+As these additional productions are added internally to the grammar a callback functionality is provided to let you know when such an event occurs.  The callback proc object can either be specified when the CFG object is created, or by using the {RLTK::CFG#callback} method.  The callback will receive three arguments: the production generated, the operator that triggered the generation, and a symbol (:first or :second) specifying which clause of the production this callback is for.
+
+### Helper Functions
+
+Once a grammar has been defined you can use the following functions to obtain information about it:
+
+* {RLTK::CFG#first_set} - Returns the *first set* for the provided symbol or sentence.
+* {RLTK::CFG#follow_set} - Returns the *follow set* for the provided symbol.
+* {RLTK::CFG#nonterms} - Returns a list of the non-terminal symbols used in the grammar's definition.
+* {RLTK::CFG#productions} - Provides either a hash or array of the grammar's productions.
+* {RLTK::CFG#symbols} - Returns a list of all symbols used in the grammar's definition.
+* {RLTK::CFG#terms} - Returns a list of the terminal symbols used in the grammar's definition.
+
 ## Parsers
 
 To create a parser using RLTK simply subclass RLTK::Parser, define the productions of the grammar you wish to parse, and call `finalize`.  During finalization RLTK will build an LALR(1) parsing table, which may contain conflicts that can't be resolved with LALR(1) lookahead sets or precedence/associativity information.  Traditionally, when parser generators such as **YACC** encounter conflicts during parsing table generation they will resolve shift/reduce conflicts in favor of shifts and reduce/reduce conflicts in favor of the production that was defined first.  This means that the generated parsers can't handle ambiguous grammars.
@@ -149,18 +202,20 @@ RLTK parsers, on the other hand, can handle *all* context-free grammars by forki
 
 Let us look at the simple prefix calculator included with RLTK:
 
-	class PrefixCalc < RLTK::Parser
-		production(:e) do
-			clause('NUM') {|n| n}
-			
-			clause('PLS e e') { |_, e0, e1| e0 + e1 }
-			clause('SUB e e') { |_, e0, e1| e0 - e1 }
-			clause('MUL e e') { |_, e0, e1| e0 * e1 }
-			clause('DIV e e') { |_, e0, e1| e0 / e1 }
-		end
-		
-		finalize
-	end
+```Ruby
+class PrefixCalc < RLTK::Parser
+  production(:e) do
+    clause('NUM') {|n| n}
+
+    clause('PLS e e') { |_, e0, e1| e0 + e1 }
+    clause('SUB e e') { |_, e0, e1| e0 - e1 }
+    clause('MUL e e') { |_, e0, e1| e0 * e1 }
+    clause('DIV e e') { |_, e0, e1| e0 / e1 }
+  end
+
+  finalize
+end
+```
 
 The parser uses the same method for defining productions as the {RLTK::CFG} class.  In fact, the parser forwards the {RLTK::Parser.production} and {RLTK::Parser.clause} method invocations to an internal {RLTK::CFG} object after removing the parser specific information.  To see a detailed description of grammar definitions please read the Context-Free Grammars section bellow.
 
@@ -172,39 +227,67 @@ The default starting symbol of the grammar is the left-hand side of the first pr
 
 ### Shortcuts
 
-RLTK provides several shortcuts for common grammar constructs.  Right now these shortcuts include the {RLTK::Parser.empty_list} and {RLTK::Parser.nonempty_list} methods.  An empty list is a list that may contain 0, 1, or more elements, with a given token seperating each element.  A non-empty list contains **at least** 1 element.
+RLTK provides several shortcuts for common grammar constructs.  Right now these shortcuts include the {RLTK::Parser.list} and {RLTK::Parser.nonempty_list} methods.  A list may contain 0, 1, or more elements, with an optional token or tokens seperating each element.  A non-empty list contains **at least** 1 element.  An empty list with only a single list element and an empty separator is equivelent to the Kleene star.  Simillarly, a list with only a single list element and an empty separator is equivelent to the Kleene plus.
 
 This example shows how these shortcuts may be used to define a list of integers separated by a `:COMMA` token:
 
-	class ListParser < RLTK::Parser
-		nonempty_list(:int_list, :INT, :COMMA)
-		
-		finalize
-	end
+```Ruby
+class ListParser < RLTK::Parser
+  nonempty_list(:int_list, :INT, :COMMA)
+
+  finalize
+end
+```
 
 If you wanted to define a list of floats or integers you could define your parser like this:
 
-	class ListParser < RLTK::Parser
-		nonempty_list(:mixed_list, [:INT, :FLOAT], :COMMA)
-		
-		finalize
-	end
+```Ruby
+class ListParser < RLTK::Parser
+  nonempty_list(:mixed_list, [:INT, :FLOAT], :COMMA)
+
+  finalize
+end
+```
+
+If you don't want to require a separator you can do this:
+
+```Ruby
+class ListParser < RLTK::Parser
+  nonempty_list(:mixed_nonsep_list, [:INT, :FLOAT])
+
+  finalize
+end
+```
+
+You can also use separators that are made up of multiple tokens:
+
+```Ruby
+class ListParser < RLTK::Parser
+  nonempty_list(:mixed_nonsep_list, [:INT, :FLOAT], 'COMMA NEWLINE?')
+
+  finalize
+end
+```
 
 A list may also contain multiple tokens between the separator:
 
-	class ListParser < RLTK::Parser
-		nonempty_list(:foo_bar_list, 'FOO BAR', :COMMA)
-		
-		finalize
-	end
+```Ruby
+class ListParser < RLTK::Parser
+  nonempty_list(:foo_bar_list, 'FOO BAR', :COMMA)
+
+  finalize
+end
+```
 
 Lastly, you can mix all of these features together:
 
-	class ListParser < RLTK::Parser
-		nonempty_list(:foo_list, ['FOO BAR', 'FOO BAZ+'], :COMMA)
-		
-		finalize
-	end
+```Ruby
+class ListParser < RLTK::Parser
+  nonempty_list(:foo_list, ['FOO BAR', 'FOO BAZ+'], :COMMA)
+
+  finalize
+end
+```
 
 The productions generated by these shortcuts will always evaluate to an array.  In the first two examples above the productions will produce a 1-D array containing the values of the `INT` or `FLOAT` tokens.  In the last two examples the productions `foo_bar_list` and `foo_list` will produce 2-D arrays where the top level array is composed of tuples coresponding to the values of `FOO`, and `BAR` or one or more `BAZ`s.
 
@@ -220,48 +303,83 @@ To assign precedence to terminal symbols you can use the {RLTK::Parser.left}, {R
 
 Let's look at the infix calculator example now:
 
-	class InfixCalc < Parser
-		
-		left :PLS, :SUB
-		right :MUL, :DIV
-		
-		production(:e) do
-			clause('NUM') { |n| n }
-			
-			clause('LPAREN e RPAREN') { |_, e, _| e }
-			
-			clause('e PLS e') { |e0, _, e1| e0 + e1 }
-			clause('e SUB e') { |e0, _, e1| e0 - e1 }
-			clause('e MUL e') { |e0, _, e1| e0 * e1 }
-			clause('e DIV e') { |e0, _, e1| e0 / e1 }
-		end
-		
-		finalize
-	end
-
-Here we use associativity information to properly deal with the different precedence of the addition, subtraction, multiplication, and division operators.  The PLS and SUB terminals are given left associativity with precedence of 1 (by default all terminals and productions have precedence of zero, which is to say no precedence), and the MUL and DIV terminals are given right associativity with precedence of 1.
-
-### Array Arguments
-
-By default the proc objects associated with productions are passed one argument for each symbol on the right-hand side of the production.  This can lead to long, unwieldy argument lists.  To have your parser pass in an array of the values of the right-hand side symbols as the only argument to procs you may use the {RLTK::Parser.array_args} method.  It must be invoked before any productions are declared, and affects all proc objects passed to `production` and `clause` methods.
+```Ruby
+class InfixCalc < RLTK::Parser
+
+  left  :PLS, :SUB
+  right :MUL, :DIV
+
+  production(:e) do
+    clause('NUM') { |n| n }
+
+    clause('LPAREN e RPAREN') { |_, e, _| e }
+
+    clause('e PLS e') { |e0, _, e1| e0 + e1 }
+    clause('e SUB e') { |e0, _, e1| e0 - e1 }
+    clause('e MUL e') { |e0, _, e1| e0 * e1 }
+    clause('e DIV e') { |e0, _, e1| e0 / e1 }
+  end
+
+  finalize
+end
+```
+
+The standard order of mathematical operations tells us that the correct way to group the operations in the expression `2 + 3 * 4` is `2 + (3 * 4)`.  However, our grammar tells us that `(2 + 3) * 5` is also a valid way to parse the expression, leading to a shift/reduce error in the parser.  To get rid of the shift/reduce error we need some way to tell the parser how to distinguish between these two parse trees.  This is where associativity comes in.  If the parser has already read `NUM PLS NUM` and the current symbol is a `MUL` symbol we want to tell the parser to shift the new `MUL` symbol onto the stack and continue on.  We do this by making the `MUL` symbol right associative.  When the parser generator encounters a shift/reduce error it looks at the token currently being read.  If it has no associativity information, the error can't be resolved; if the token is left associative, it will remove the shift action from the parser (leaving only the reduce action); if the token is right associative, it will remove the reduce action from the parser (leaving only the shift action).
+
+Now, let us consider the expression `3 - 2 - 1`.  Here, the correct way to parse the expression is `(3 - 2) - 2`.  To ensure that this case is selected over `3 - (2 - 1)` we can make the `SUB` token left associative.  This will cause the symbols `NUM SUB NUM` to be reduced before the second `SUB` symbol is shifted onto the parse stack.
+
+Not that, to resolve a shift/reduce or reduce/reduce conflict, precedence and associativty information must be present for all actions involved in the conflict.  As such, it isn't enough to simply make the `MUL` and `DIV` tokens right associative; we must also make the `PLS` and `SUB` tokens left associative.
+
+### Token Selectors
+
+In many cases productions contain tokens who's value is unimportant.  In such situations passing `nil` to the production's action is not useful.  To prevent this happening you may use *token selectors*.  By placing a period (`.`) in front of a token you can indicate to the parser that the following token is important and you wish for its value to be passed to the action.  In the following example selectors are used to only pass the sub-expressions' values to the action:
+
+```Ruby
+class InfixCalc < RLTK::Parser
+
+  left  :PLS, :SUB
+  right :MUL, :DIV
+
+  production(:e) do
+    clause('NUM') { |n| n }
+
+    clause('LPAREN .e RPAREN') { |e| e }
+
+    clause('.e PLS .e') { |e0, e1| e0 + e1 }
+    clause('.e SUB .e') { |e0, e1| e0 - e1 }
+    clause('.e MUL .e') { |e0, e1| e0 * e1 }
+    clause('.e DIV .e') { |e0, e1| e0 / e1 }
+  end
+
+  finalize
+end
+```
+
+### Argument Passing for Actions
+
+By default the proc objects associated with productions are passed one argument for each symbol on the right-hand side of the production.  This can lead to long, unwieldy argument lists.  To change this behaviour you can use the {RLTK::Parser.default_arg_type} method, which accepts the `:splat` (default) and `:array` arguments.  Any production actions that are defined after a call to {RLTK::Parser.default_arg_type} will use the argument passing method currently set as the default.  You can switch between the different argument passing methods by calling {RLTK::Parser.default_arg_type} repeatedly.
+
+Individual productions may specify the argument type used by their action via the `arg_type` parameter.  If the {RLTK::Parser.production} method is passed an argument type and a block, any clauses defined inside the block will use the argument type specified by the `arg_type` parameter.
 
 ### The Parsing Environment
 
 The parsing environment is the context in which the proc objects associated with productions are evaluated, and can be used to provide helper functions and to keep state while parsing.  To define a custom environment simply subclass {RLTK::Parser::Environment} inside your parser definition as follows:
 
-	class MyParser < RLTK::Parser
-		...
-		
-		finalize
-		
-		class Environment < Environment
-			def helper_function
-				...
-			end
-			
-			...
-		end
-	end
+```Ruby
+class MyParser < RLTK::Parser
+  ...
+
+  class Environment < Environment
+    def helper_function
+    ...
+    end
+
+  ...
+  end
+
+  finalize
+end
+```
 
 (The definition of the Environment class may occur anywhere inside the MyParser class definition.)
 
@@ -320,23 +438,29 @@ The value of an `ERROR` non-terminal will be an array containing all of the toke
 
 The example below, based on one of the unit tests, shows a very basic usage of error productions:
 
-	class ErrorCalc < RLTK::Parser
-		left :ERROR
-		right :PLS, :SUB, :MUL, :DIV, :NUM
-		
-		production(:e) do
-			clause('NUM') {|n| n}
-		
-			clause('e PLS e') { |e0, _, e1| e0 + e1 }
-			clause('e SUB e') { |e0, _, e1| e0 - e1 }
-			clause('e MUL e') { |e0, _, e1| e0 * e1 }
-			clause('e DIV e') { |e0, _, e1| e0 / e1 }
-		
-			clause('e PLS ERROR e') { |e0, _, err, e1| error("#{err.len} tokens skipped."); e0 + e1 }
-		end
-	
-		finalize
-	end
+```Ruby
+class ErrorCalc < RLTK::Parser
+  left  :ERROR
+  right :PLS, :SUB, :MUL, :DIV, :NUM
+
+  production(:e) do
+    clause('NUM') {|n| n}
+
+    clause('e PLS e') { |e0, _, e1| e0 + e1 }
+    clause('e SUB e') { |e0, _, e1| e0 - e1 }
+    clause('e MUL e') { |e0, _, e1| e0 * e1 }
+    clause('e DIV e') { |e0, _, e1| e0 / e1 }
+
+    clause('e PLS ERROR e') { |e0, _, err, e1| error("#{err.len} tokens skipped."); e0 + e1 }
+  end
+
+  finalize
+end
+```
+
+## A Note on Token Naming
+
+In the world of RLTK both terminal and non-terminal symbols may contain only alphanumeric characters and underscores.  The differences between terminal and non-terminal symbols is that terminals are **ALL\_UPPER\_CASE** and non-terminals are **all\_lower\_case**.
 
 ## ASTNode
 
@@ -345,42 +469,48 @@ The {RLTK::ASTNode} base class is meant to be a good starting point for implemen
 To create your own AST node classes you subclass the {RLTK::ASTNode} class and then use the {RLTK::ASTNode.child} and {RLTK::ASTNode.value} methods.  By declaring the children and values of a node the class will define the appropriate accessors with type checking, know how to pack and unpack a node's children, and know how to handle constructor arguments.
 
 Here we can see the definition of several AST node classes that might be used to implement binary operations for a language:
-	
-	class Expression < RLTK::ASTNode; end
-	
-	class Number < Expression
-		value :value, Fixnum
-	end
-	
-	class BinOp < Expression
-		value :op, String
-		
-		child :left,  Expression
-		child :right, Expression
-	end
-
-The assignment functions that are generated for the children and values perform type checking to make sure that the AST is well-formed.  The type of a child must be a subclass of the {RLTK::ASTNode} class, whereas the type of a value must **NOT** be a subclass of the {RLTK::ASTNode} class.  While child and value objects are stored as instance variables it is unsafe to assign to these variables directly, and it is strongly recommended to always use the accessor functions.
+
+```Ruby
+class Expression < RLTK::ASTNode; end
+
+class Number < Expression
+  value :value, Fixnum
+end
+
+class BinOp < Expression
+  value :op, String
+
+  child :left,  Expression
+  child :right, Expression
+end
+```
+
+The assignment functions that are generated for the children and values perform type checking to make sure that the AST is well-formed.  The type of a child must be a subclass of the {RLTK::ASTNode} class, whereas the type of a value can be any Ruby class.  While child and value objects are stored as instance variables it is unsafe to assign to these variables directly, and it is strongly recommended to always use the accessor functions.
 
 When instantiating a subclass of {RLTK::ASTNode} the arguments to the constructor should be the node's values (in order of definition) followed by the node's children (in order of definition).  If a constructor is given fewer arguments then the number of values and children the remaining arguments are assumed to be `nil`.  Example:
 
-	class Foo < RLTK::ASTNode
-		value :a, Fixnum
-		child :b, Bar
-		value :c, String
-		child :d, Bar
-	end
-	
-	class Bar < RLTK::ASTNode
-		value :a, String
-	end
-	
-	Foo.new(1, 'baz', Bar.new)
+```Ruby
+class Foo < RLTK::ASTNode
+  value :a, Fixnum
+  child :b, Bar
+  value :c, String
+  child :d, Bar
+end
+
+class Bar < RLTK::ASTNode
+  value :a, String
+end
+
+Foo.new(1, 'baz', Bar.new)
+```
 
 Lastly, the type of a child or value can be defined as an array of objects of a specific type as follows:
 
-	class Foo < RLTK::ASTNode
-		value :strings, [String]
-	end
+```Ruby
+class Foo < RLTK::ASTNode
+  value :strings, [String]
+end
+```
 
 ### Tree Iteration and Mapping
 
@@ -398,15 +528,6 @@ You can also map one tree to another tree using the {RLTK::ASTNode#map} and {RLT
 
 RLTK supports the generation of native code and LLVM IR, as well as JIT compilation and execution, through the {RLTK::CG} module.  This module is built on top of bindings to [LLVM](http://llvm.org) and provides much, though not all, of the functionality of the LLVM libraries.
 
-A small amount of the functionality of the RLTK::CG module requires the [LLVM Extended C Bindings](https://github.com/chriswailes/llvm-ecb) library.  If this library is missing the rest of the module should behave properly, but this functionality will be missing.  The features that require this library are:
-
-* **Shared Library Loading** - Load shared libraries into the process so that their exported symbols are visible to LLVM via the {RLTK::CG::Support.load\_library} method.
-* **ASM Printer and Parser Initialization** - Available through the {RLTK::CG::LLVM.init\_asm\_parser} and {RLTK::CG::LLVM.init\_asm\_printer} methods.
-* **LLVM IR Loading** - LLVM IR files can be loaded into RLTK via the {RLTK::CG::Module.read\_ir\_file} method.
-* **Value Printing** - Print any value's LLVM IR to a given file descriptor using {RLTK::CG::Value#print}.
-* **Targets, Target Data, and Target Machines** - Manipulate LLVM structures that contain data about the target environment.
-* **Object File Generation** - LLVM Modules can be compiled to object files via the {RLTK::CG::Module#compile} method.
-
 ### Acknowledgments and Discussion
 
 Before we get started with the details, I would like to thank [Jeremy Voorhis](https://github.com/jvoorhis/).  The bindings present in RLTK are really a fork of the great work that he did on [ruby-llvm](https://github.com/jvoorhis/ruby-llvm).
@@ -468,40 +589,54 @@ Functions in LLVM are much like C functions; they have a return type, argument t
 
 The first way to create functions is via a module's function collection:
 
-	mod.functions.add('my function', RLTK::CG::NativeIntType, [RLTK::CG::NativeIntType, RLTK::CG::NativeIntType])
+```Ruby
+mod.functions.add('my function', RLTK::CG::NativeIntType, [RLTK::CG::NativeIntType, RLTK::CG::NativeIntType])
+```
 
 Here we have defined a function named 'my function' in the `mod` module.  It takes two native integers as arguments and returns a native integer.  It is also possible to define the type of a function ahead of time and pass it to this method:
 
-	type = RLTK::CG::FunctionType.new(RLTK::CG::NativeIntType, [RLTK::CG::NativeIntType, RLTK::CG::NativeIntType])
-	mod.functions.add('my function', type)
+```Ruby
+type = RLTK::CG::FunctionType.new(RLTK::CG::NativeIntType, [RLTK::CG::NativeIntType, RLTK::CG::NativeIntType])
+mod.functions.add('my function', type)
+```
 
 Functions may also be created directly via the {RLTK::CG::Function#initialize RLTK::CG::Function.new} method, though a reference to a module is still necessary:
 
-	mod = Module.new('my module')
-	fun = Function.new(mod, 'my function', RLTK::CG::NativeIntType, [RLTK::CG::NativeIntType, RLTK::CG::NativeIntType])
+```Ruby
+mod = Module.new('my module')
+fun = Function.new(mod, 'my function', RLTK::CG::NativeIntType, [RLTK::CG::NativeIntType, RLTK::CG::NativeIntType])
+```
 
 or
-	
-	mod  = Module.new('my module')
-	type = RLTK::CG::FunctionType.new(RLTK::CG::NativeIntType, [RLTK::CG::NativeIntType, RLTK::CG::NativeIntType])
-	fun  = Function.new(mod, 'my function', type)
+
+```Ruby
+mod  = Module.new('my module')
+type = RLTK::CG::FunctionType.new(RLTK::CG::NativeIntType, [RLTK::CG::NativeIntType, RLTK::CG::NativeIntType])
+fun  = Function.new(mod, 'my function', type)
+```
 
 Lastly, whenever you use one of these methods to create a function you may give it a block to be executed inside the context of the function object.  This allows for easier building of functions:
 
-	mod.functions.add('my function', RLTK::CG::NativeIntType, [RLTK::CG::NativeIntType, RLTK::CG::NativeIntType]) do
-		bb = blocks.append('entry)'
-		...
-	end
+```Ruby
+mod.functions.add('my function', RLTK::CG::NativeIntType, [RLTK::CG::NativeIntType, RLTK::CG::NativeIntType]) do
+  bb = blocks.append('entry)'
+  ...
+end
+```
 
 ### Basic Blocks
 
 Once a function has been added to a module you will need to add {RLTK::CG::BasicBlock BasicBlocks} to the function.  This can be done easily:
 
-	bb = fun.blocks.append('entry')
+```Ruby
+bb = fun.blocks.append('entry')
+```
 
 We now have a basic block that we can use to add instructions to our function and get it to actually do something.  You can also instantiate basic blocks directly:
 
-	bb = RLTK::CG::BasicBlock.new(fun, 'entry')
+```Ruby
+bb = RLTK::CG::BasicBlock.new(fun, 'entry')
+```
 
 ### The Builder
 
@@ -509,121 +644,151 @@ Now that you have a basic block you need to add instructions to it.  This is acc
 
 To add instructions using a builder directly (this is most similar to how it is done using C/C++) you create the builder, position it where you want to add instructions, and then build them:
 
-	fun = mod.functions.add('add', RLTK::CG::NativeIntType, [RLTK::CG::NativeIntType, RLTK::CG::NativeIntType])
-	bb  = fun.blocks.append('entry')
-	
-	builder = RLTK::CG::Builder.new
-	
-	builder.position_at_end(bb)
-	
-	# Generate an add instruction.
-	inst0 = builder.add(fun.params[0], fun.params[1])
-	
-	# Generate a return instruction.
-	builder.ret(inst0)
+```Ruby
+fun = mod.functions.add('add', RLTK::CG::NativeIntType, [RLTK::CG::NativeIntType, RLTK::CG::NativeIntType])
+bb  = fun.blocks.append('entry')
+
+builder = RLTK::CG::Builder.new
+
+builder.position_at_end(bb)
+
+# Generate an add instruction.
+inst0 = builder.add(fun.params[0], fun.params[1])
+
+# Generate a return instruction.
+builder.ret(inst0)
+```
 
 You can get rid of some of those references to the builder by using the {RLTK::CG::Builder#build} method:
 
-	fun = mod.functions.add('add', RLTK::CG::NativeIntType, [RLTK::CG::NativeIntType, RLTK::CG::NativeIntType])
-	bb  = fun.blocks.append('entry')
-	
-	builder = RLTK::CG::Builder.new
-	
-	builder.build(bb) do
-		ret add(fun.params[0], fun.params[1])
-	end
+```Ruby
+fun = mod.functions.add('add', RLTK::CG::NativeIntType, [RLTK::CG::NativeIntType, RLTK::CG::NativeIntType])
+bb  = fun.blocks.append('entry')
+
+builder = RLTK::CG::Builder.new
+
+builder.build(bb) do
+  ret add(fun.params[0], fun.params[1])
+end
+```
 
 To get rid of more code:
 
-	fun = mod.functions.add('add', RLTK::CG::NativeIntType, [RLTK::CG::NativeIntType, RLTK::CG::NativeIntType])
-	bb  = fun.blocks.append('entry')
-	
-	RLTK::CG::Builder.new(bb) do
-		ret add(fun.params[0], fun.params[1])
-	end
+```Ruby
+fun = mod.functions.add('add', RLTK::CG::NativeIntType, [RLTK::CG::NativeIntType, RLTK::CG::NativeIntType])
+bb  = fun.blocks.append('entry')
+
+RLTK::CG::Builder.new(bb) do
+  ret add(fun.params[0], fun.params[1])
+end
+```
 
-Or:
+or
 
-	fun = mod.functions.add('add', RLTK::CG::NativeIntType, [RLTK::CG::NativeIntType, RLTK::CG::NativeIntType])
-	fun.blocks.append('entry') do
-		ret add(fun.params[0], fun.params[1])
-	end
+```Ruby
+fun = mod.functions.add('add', RLTK::CG::NativeIntType, [RLTK::CG::NativeIntType, RLTK::CG::NativeIntType])
+fun.blocks.append('entry') do
+  ret add(fun.params[0], fun.params[1])
+end
+```
 
-Or even:
+or even
 
-	mod.functions.add('add', RLTK::CG::NativeIntType, [RLTK::CG::NativeIntType, RLTK::CG::NativeIntType]) do
-		blocks.append('entry') do |fun|
-			ret add(fun.params[0], fun.params[1])
-		end
-	end
+```Ruby
+mod.functions.add('add', RLTK::CG::NativeIntType, [RLTK::CG::NativeIntType, RLTK::CG::NativeIntType]) do
+  blocks.append('entry') do |fun|
+    ret add(fun.params[0], fun.params[1])
+  end
+end
+```
 
 In the last two examples a new builder object is created for the block.  It is possible to specify the builder to be used:
 
-	builder = RLTK::CG::Builder.new
-	
-	mod.functions.add('add', RLTK:CG::NativeIntType, [RLTK::CG::NativeIntType, RLTK::CG::NativeIntType]) do
-		blocks.append('entry', builder) do |fun|
-			ret add(fun.params[0], fun.params[1])
-		end
-	end
+```Ruby
+builder = RLTK::CG::Builder.new
+
+mod.functions.add('add', RLTK:CG::NativeIntType, [RLTK::CG::NativeIntType, RLTK::CG::NativeIntType]) do
+  blocks.append('entry', builder) do |fun|
+    ret add(fun.params[0], fun.params[1])
+  end
+end
+```
 
 For an example of where this is useful, see the Kazoo tutorial.
 
-### Execution Engines
+### The Contractor
 
-Once you have generated your code you may want to run it.  RLTK provides bindings to both the LLVM interpreter and JIT compiler to help you do just that.  Creating a JIT compiler is pretty simple.
+An alternative to using the {RLTK::CG::Builder} class is to use the {RLTK::CG::Contractor} class, which is a subclass of the Builder and includes the Filigree::Visitor module. (Get it? It's a visiting builder!)  By subclassing the Contractor you can define blocks of code for handling various types of AST nodes and leave the selection of the correct code up to the {RLTK::CG::Contractor#visit} method.  In addition, the `:at` and `:rcb` options to the *visit* method make it much easier to manage the positioning of the Builder.
 
-	mod = RLTK::CG::Module.new('my module')
-	jit = RLTK::CG::JITCompiler(mod)
-	
-	mod.functions.add('add', RLTK:CG::NativeIntType, [RLTK::CG::NativeIntType, RLTK::CG::NativeIntType]) do
-		blocks.append('entry', nil, nil, self) do |fun|
-			ret add(fun.params[0], fun.params[1])
-		end
-	end
+Here we can see how easy it is to define a block that builds the instructions for binary operations:
 
-Now you can run your 'add' function like this:
+```Ruby
+on Binary do |node|
+  left  = visit node.left
+  right = visit node.right
 
-	jit.run(fun, 1, 2)
+  case node
+    when Add then fadd(left, right, 'addtmp')
+    when Sub then fsub(left, right, 'subtmp')
+    when Mul then fmul(left, right, 'multmp')
+    when Div then fdiv(left, right, 'divtmp')
+    when LT  then ui2fp(fcmp(:ult, left, right, 'cmptmp'), RLTK::CG::DoubleType, 'booltmp')
+  end
+end
+```
 
-The result will be a {RLTK::CG::GenericValue} object, and you will want to use its {RLTK::CG::GenericValue#to\_i #to\_i} and {RLTK::CG::GenericValue#to\_f #to\_f} methods to get the Ruby value result.
+AST nodes whos translation requires the generation of control flow will require the creation of new BasicBlocks and the repositioning of the builder.  This can be easily managed:
 
-## Context-Free Grammars
+```Ruby
+on If do |node|
+  cond_val = visit node.cond
+  fcmp :one, cond_val, ZERO, 'ifcond'
 
-The {RLTK::CFG} class provides an abstraction for context-free grammars.  For the purpose of this class terminal symbols appear in **ALL CAPS**, and non-terminal symbols appear in **all lowercase**.  Once a grammar is defined the {RLTK::CFG#first_set} and {RLTK::CFG#follow_set} methods can be used to find *first* and *follow* sets.
+  start_bb = current_block
+  fun      = start_bb.parent
 
-### Defining Grammars
+  then_bb               = fun.blocks.append('then')
+  then_val, new_then_bb = visit node.then, at: then_bb, rcb: true
 
-A grammar is defined by first instantiating the {RLTK::CFG} class.  The {RLTK::CFG#production} and {RLTK::CFG#clause} methods may then be used to define the productions of the grammar.  The `production` method can take a Symbol denoting the left-hand side of the production and a string describing the right-hand side of the production, or the left-hand side symbol and a block.  In the first usage a single production is created.  In the second usage the block may contain repeated calls to the `clause` method, each call producing a new production with the same left-hand side but different right-hand sides.  {RLTK::CFG#clause} may not be called outside of {RLTK::CFG#production}.  Bellow we see a grammar definition that uses both methods:
+  else_bb               = fun.blocks.append('else')
+  else_val, new_else_bb = visit node.else, at: else_bb, rcb: true
 
-	grammar = RLTK::CFG.new
-	
-	grammar.production(:s) do
-		clause('A G D')
-		clause('A a C')
-		clause('B a D')
-		clause('B G C')
-	end
-	
-	grammar.production(:a, 'b')
-	grammar.production(:b, 'G')
+  merge_bb = fun.blocks.append('merge', self)
+  phi_inst = build(merge_bb) { phi RLTK::CG::DoubleType, {new_then_bb => then_val, new_else_bb => else_val}, 'iftmp' }
 
-### Extended Backus–Naur Form
+  build(start_bb) { cond cond_val, then_bb, else_bb }
 
-The RLTK::CFG class understands grammars written in the extended Backus–Naur form.  This allows you to use the \*, \+, and ? operators in your grammar definitions.  When each of these operators are encountered additional productions are generated.  For example, if the right-hand side of a production contained 'NUM*' a production of the form 'num_star -> | NUM num_star' is added to the grammar.  As such, your grammar should not contain productions with similar left-hand sides (e.g. foo_star, bar_question, or baz_plus).
+  build(new_then_bb) { br merge_bb }
+  build(new_else_bb) { br merge_bb }
 
-As these additional productions are added internally to the grammar a callback functionality is provided to let you know when such an event occurs.  The callback proc object can either be specified when the CFG object is created, or by using the {RLTK::CFG#callback} method.  The callback will receive three arguments: the production generated, the operator that triggered the generation, and a symbol (:first or :second) specifying which clause of the production this callback is for.
+  returning(phi_inst) { target merge_bb }
+end
+```
 
-### Helper Functions
+More extensive examples of how to use the Contractor class can be found in the Kazoo tutorial chapters.
 
-Once a grammar has been defined you can use the following functions to obtain information about it:
+### Execution Engines
 
-* {RLTK::CFG#first_set} - Returns the *first set* for the provided symbol or sentence.
-* {RLTK::CFG#follow_set} - Returns the *follow set* for the provided symbol.
-* {RLTK::CFG#nonterms} - Returns a list of the non-terminal symbols used in the grammar's definition.
-* {RLTK::CFG#productions} - Provides either a hash or array of the grammar's productions.
-* {RLTK::CFG#symbols} - Returns a list of all symbols used in the grammar's definition.
-* {RLTK::CFG#terms} - Returns a list of the terminal symbols used in the grammar's definition.
+Once you have generated your code you may want to run it.  RLTK provides bindings to both the LLVM interpreter and JIT compiler to help you do just that.  Creating a JIT compiler is pretty simple.
+
+```Ruby
+mod = RLTK::CG::Module.new('my module')
+jit = RLTK::CG::JITCompiler(mod)
+
+mod.functions.add('add', RLTK:CG::NativeIntType, [RLTK::CG::NativeIntType, RLTK::CG::NativeIntType]) do
+  blocks.append('entry', nil, nil, self) do |fun|
+    ret add(fun.params[0], fun.params[1])
+  end
+end
+```
+
+Now you can run your 'add' function like this:
+
+```Ruby
+jit.run(fun, 1, 2)
+```
+
+The result will be a {RLTK::CG::GenericValue} object, and you will want to use its {RLTK::CG::GenericValue#to\_i #to\_i} and {RLTK::CG::GenericValue#to\_f #to\_f} methods to get the Ruby value result.
 
 ## Tutorial
 
@@ -637,22 +802,24 @@ The Kazoo toy language is a procedural language that allows you to define functi
 
 Because we want to keep things simple the only datatype in Kazoo is a 64-bit floating point type (a C double or a Ruby float).  As such, all values are implicitly double precision and the language doesn’t require type declarations.  This gives the language a very nice and simple syntax.  For example, the following example computes Fibonacci numbers:
 
-	def fib(x)
-		if x < 3 then
-			1
-		else
-			fib(x-1) + fib(x-2)
+```
+def fib(x)
+  if x < 3 then
+    1
+  else
+    fib(x-1) + fib(x-2)
+```
 
 The tutorial is organized as follows:
 
-  * [Chapter 1: The Lexer](file.Chapter1.html)
-  * [Chapter 2: The AST Nodes](file.Chapter2.html)
-  * [Chapter 3: The Parser](file.Chapter3.html)
-  * [Chapter 4: AST Translation](file.Chapter4.html)
-  * [Chapter 5: JIT Compilation](file.Chapter5.html)
-  * [Chapter 6: Adding Control Flow](file.Chapter6.html)
-  * [Chapter 7: Playtime](file.Chapter7.html)
-  * [Chapter 8: Mutable Variables](file.Chapter8.html)
+  * [Chapter 1: The Lexer](https://github.com/chriswailes/RLTK/blob/master/examples/kazoo/chapter%201/Chapter1.md)
+  * [Chapter 2: The AST Nodes](https://github.com/chriswailes/RLTK/blob/master/examples/kazoo/chapter%202/Chapter2.md)
+  * [Chapter 3: The Parser](https://github.com/chriswailes/RLTK/blob/master/examples/kazoo/chapter%203/Chapter3.md)
+  * [Chapter 4: AST Translation](https://github.com/chriswailes/RLTK/blob/master/examples/kazoo/chapter%204/Chapter4.md)
+  * [Chapter 5: JIT Compilation](https://github.com/chriswailes/RLTK/blob/master/examples/kazoo/chapter%205/Chapter5.md)
+  * [Chapter 6: Adding Control Flow](https://github.com/chriswailes/RLTK/blob/master/examples/kazoo/chapter%206/Chapter6.md)
+  * [Chapter 7: Playtime](https://github.com/chriswailes/RLTK/blob/master/examples/kazoo/chapter%207/Chapter7.md)
+  * [Chapter 8: Mutable Variables](https://github.com/chriswailes/RLTK/blob/master/examples/kazoo/chapter%208/Chapter8.md)
 
 Before starting this tutorial you should know about regular expressions, the basic ideas behind lexing and parsing, and be able to read context-free grammar (CFG) definitions.  By the end of this tutorial we will have written 372 lines of source code and have a JIT compiler for a Turing complete language.
 
@@ -668,10 +835,16 @@ The following lexer and parser classes are included as part of RLTK:
 
 ## Contributing
 
-If you are interested in contributing to RLTK you can:
+If you are interested in contributing to RLTK there are many aspects of the library that you can work on.  A detailed TODO list can be found [here](https://github.com/chriswailes/RLTK/blob/master/TODO.md).  If you are looking for smaller units of work feel free to:
 
 * Help provide unit tests.  Not all of RLTK is tested as well as it could be.  Specifically, more tests for the RLTK::CFG and RLTK::Parser classes would be appreciated.
 * Write lexers or parsers that you think others might want to use.  Possibilities include HTML, JSON/YAML, Javascript, and Ruby.
-* Write a class for dealing with regular languages.
 * Extend the RLTK::CFG class with additional functionality.
-* Let me know if you found any part of this documentation unclear or incomplete.
+
+Lastly, I love hearing back from users.  If you find any part of the documentation unclear or incomplete let me know.  It is also helpful to me to know how people are using the library, so if you are using RLTK in your project send me an email.  This lets me know what features are being used and where I should focus my development efforts.
+
+## News
+
+Aaaaand we're back.  Development of RLTK has been on hold for a while as I worked on other projects.  If you want to see what I've been up to, you can check out [Clang's](http://llvm.org/clang) new `-Wconsumed` flag and the [Filigree](http://github.com/chriswailes/filigree) gem.
+
+The next version of RLTK is going to be updated to require Ruby 2.0 as well as LLVM 3.4.  Previous versions of RLTK required my LLVM-ECB libarary to expose extra LLVM features through the C bindings; this is no longer necessary as this functionality has been moved into LLVM proper.  If anyone has any requests for new or improved features for RLTK version 3.0, let me know.