swift-pyrite 0.1.0

data/vendor/bundle/ruby/2.0.0/gems/rspec-support-3.3.0/lib/rspec/support.rb

@@ -0,0 +1,111 @@
+module RSpec
+  module Support
+    # @api private
+    #
+    # Defines a helper method that is optimized to require files from the
+    # named lib. The passed block MUST be `{ |f| require_relative f }`
+    # because for `require_relative` to work properly from within the named
+    # lib the line of code must be IN that lib.
+    #
+    # `require_relative` is preferred when available because it is always O(1),
+    # regardless of the number of dirs in $LOAD_PATH. `require`, on the other
+    # hand, does a linear O(N) search over the dirs in the $LOAD_PATH until
+    # it can resolve the file relative to one of the dirs.
+    def self.define_optimized_require_for_rspec(lib, &require_relative)
+      name = "require_rspec_#{lib}"
+
+      if Kernel.respond_to?(:require_relative)
+        (class << self; self; end).__send__(:define_method, name) do |f|
+          require_relative.call("#{lib}/#{f}")
+        end
+      else
+        (class << self; self; end).__send__(:define_method, name) do |f|
+          require "rspec/#{lib}/#{f}"
+        end
+      end
+    end
+
+    define_optimized_require_for_rspec(:support) { |f| require_relative(f) }
+    require_rspec_support "version"
+    require_rspec_support "ruby_features"
+
+    # @api private
+    KERNEL_METHOD_METHOD = ::Kernel.instance_method(:method)
+
+    # @api private
+    #
+    # Used internally to get a method handle for a particular object
+    # and method name.
+    #
+    # Includes handling for a few special cases:
+    #
+    #   - Objects that redefine #method (e.g. an HTTPRequest struct)
+    #   - BasicObject subclasses that mixin a Kernel dup (e.g. SimpleDelegator)
+    #   - Objects that undefine method and delegate everything to another
+    #     object (e.g. Mongoid association objects)
+    if RubyFeatures.supports_rebinding_module_methods?
+      def self.method_handle_for(object, method_name)
+        KERNEL_METHOD_METHOD.bind(object).call(method_name)
+      rescue NameError => original
+        begin
+          handle = object.method(method_name)
+          raise original unless handle.is_a? Method
+          handle
+        rescue Exception
+          raise original
+        end
+      end
+    else
+      def self.method_handle_for(object, method_name)
+        if ::Kernel === object
+          KERNEL_METHOD_METHOD.bind(object).call(method_name)
+        else
+          object.method(method_name)
+        end
+      rescue NameError => original
+        begin
+          handle = object.method(method_name)
+          raise original unless handle.is_a? Method
+          handle
+        rescue Exception
+          raise original
+        end
+      end
+    end
+
+    # A single thread local variable so we don't excessively pollute that namespace.
+    def self.thread_local_data
+      Thread.current[:__rspec] ||= {}
+    end
+
+    def self.failure_notifier=(callable)
+      thread_local_data[:failure_notifier] = callable
+    end
+
+    # @private
+    DEFAULT_FAILURE_NOTIFIER = lambda { |failure, _opts| raise failure }
+
+    def self.failure_notifier
+      thread_local_data[:failure_notifier] || DEFAULT_FAILURE_NOTIFIER
+    end
+
+    def self.notify_failure(failure, options={})
+      failure_notifier.call(failure, options)
+    end
+
+    def self.with_failure_notifier(callable)
+      orig_notifier = failure_notifier
+      self.failure_notifier = callable
+      yield
+    ensure
+      self.failure_notifier = orig_notifier
+    end
+
+    # The Differ is only needed when a a spec fails with a diffable failure.
+    # In the more common case of all specs passing or the only failures being
+    # non-diffable, we can avoid the extra cost of loading the differ, diff-lcs,
+    # pp, etc by avoiding an unnecessary require. Instead, autoload will take
+    # care of loading the differ on first use.
+    autoload :Differ, "rspec/support/differ"
+  end
+end

data/vendor/bundle/ruby/2.0.0/gems/treetop-1.6.3/LICENSE

@@ -0,0 +1,19 @@
+Copyright (c) 2007 Nathan Sobo.
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+THE SOFTWARE.

data/vendor/bundle/ruby/2.0.0/gems/treetop-1.6.3/README.md

@@ -0,0 +1,192 @@
+Support
+=======
+
+Support for Treetop is provided through the mailing list you can join or browse here:
+http://groups.google.com/group/treetop-dev 
+
+Tutorial
+========
+Languages can be split into two components, their *syntax* and their *semantics*. It's your understanding of English syntax that tells you the stream of words "Sleep furiously green ideas colorless" is not a valid sentence. Semantics is deeper. Even if we rearrange the above sentence to be "Colorless green ideas sleep furiously", which is syntactically correct, it remains nonsensical on a semantic level. With Treetop, you'll be dealing with languages that are much simpler than English, but these basic concepts apply. Your programs will need to address both the syntax and the semantics of the languages they interpret.
+
+Treetop equips you with powerful tools for each of these two aspects of interpreter writing. You'll describe the syntax of your language with a *parsing expression grammar*. From this description, Treetop will generate a Ruby parser that transforms streams of characters written into your language into *abstract syntax trees* representing their structure. You'll then describe the semantics of your language in Ruby by defining methods on the syntax trees the parser generates.
+
+Parsing Expression Grammars, The Basics
+=======================================
+The first step in using Treetop is defining a grammar in a file with the `.treetop` extension. Here's a grammar that's useless because it's empty:
+    
+    # my_grammar.treetop
+    grammar MyGrammar
+    end
+
+Next, you start filling your grammar with rules. Each rule associates a name with a parsing expression, like the following:
+
+    # my_grammar.treetop
+    # You can use a .tt extension instead if you wish
+    grammar MyGrammar
+      rule hello
+        'hello chomsky'
+      end
+    end
+
+The first rule becomes the *root* of the grammar, causing its expression to be matched when a parser for the grammar is fed a string. The above grammar can now be used in a Ruby program. Notice how a string matching the first rule parses successfully, but a second nonmatching string does not.
+
+```ruby
+# use_grammar.rb
+require 'rubygems'
+require 'treetop'
+Treetop.load 'my_grammar'
+# or just:
+# require 'my_grammar'                     # This works because Polyglot hooks "require" to find and load Treetop files
+    
+parser = MyGrammarParser.new
+puts parser.parse('hello chomsky')         # => Treetop::Runtime::SyntaxNode
+puts parser.parse('silly generativists!')  # => nil
+```
+Users of *regular expressions* will find parsing expressions familiar. They share the same basic purpose, matching strings against patterns. However, parsing expressions can recognize a broader category of languages than their less expressive brethren. Before we get into demonstrating that, lets cover some basics. At first parsing expressions won't seem much different. Trust that they are.
+
+Terminal Symbols
+----------------
+The expression in the grammar above is a terminal symbol. It will only match a string that matches it exactly. There are two other kinds of terminal symbols, which we'll revisit later. Terminals are called *atomic expressions* because they aren't composed of smaller expressions. A terminal symbol may use either double or single quotes. If the closing quote is immediately followed by the modifier 'i', the string is matched without case-sensitivity, that is, the input.downcase matches the terminal.downcase
+
+Treetop now also supports regular expressions as terminals. Use a string as before, but append the modifier character 'r' (you can combine this with 'i' to get case-insensitive regular expressions). Regular expressions are generally faster than the equivalent parsing expressions, but may have polynomial worst-case behaviour, which is worse than parsing expressions. Your regular expression will always be anchored (by prepending \A) to test the current location of the input, so some special expressions like \b for word boundaries may give unexpected results.
+
+Ordered Choices
+---------------
+Ordered choices are *composite expressions*, which allow for any of several subexpressions to be matched. These should be familiar from regular expressions, but in parsing expressions, they are delimited by the `/` character. Its important to note that the choices are prioritized in the order they appear. If an earlier expression is matched, no subsequent expressions are tried. Here's an example:
+
+    # my_grammar.treetop
+    grammar MyGrammar
+      rule hello
+        'hello chomsky' / 'hello lambek'
+      end
+    end
+
+```ruby    
+# fragment of use_grammar.rb
+puts parser.parse('hello chomsky')         # => Treetop::Runtime::SyntaxNode
+puts parser.parse('hello lambek')          # => Treetop::Runtime::SyntaxNode
+puts parser.parse('silly generativists!')  # => nil
+```
+Note that once a choice rule has matched the text using a particular alternative at a particular location in the input and hence has succeeded, that choice will never be reconsidered, even if the chosen alternative causes another rule to fail where a later alternative wouldn't have. It's always a later alternative, since the first to succeed is final - why keep looking when you've found what you wanted? This is a feature of PEG parsers that you need to understand if you're going to succeed in using Treetop. In order to memoize success and failures, such decisions cannot be reversed. Luckily Treetop provides a variety of clever ways you can tell it to avoid making the wrong decisions. But more on that later.
+
+Sequences
+---------
+Sequences are composed of other parsing expressions separated by spaces. Using sequences, we can tighten up the above grammar.
+
+    # my_grammar.treetop
+    grammar MyGrammar
+      rule hello
+        'hello ' ('chomsky' / 'lambek')
+      end
+    end
+
+Note the use of parentheses to override the default precedence rules, which bind sequences more tightly than choices.
+
+Once the whole sequence has been matched, the result is memoized and the details of the match will not be reconsidered for that location in the input.
+
+Nonterminal Symbols
+-------------------
+Here we leave regular expressions behind. Nonterminals allow expressions to refer to other expressions by name. A trivial use of this facility would allow us to make the above grammar more readable should the list of names grow longer.
+
+    # my_grammar.treetop
+    grammar MyGrammar
+      rule hello
+        'hello ' linguist
+      end
+      
+      rule linguist
+        'chomsky' / 'lambek' / 'jacobsen' / 'frege'
+      end
+    end
+
+The true power of this facility, however, is unleashed when writing *recursive expressions*. Here is a self-referential expression that can match any number of open parentheses followed by any number of closed parentheses. This is theoretically impossible with regular expressions due to the *pumping lemma*.
+
+    # parentheses.treetop
+    grammar Parentheses
+      rule parens
+        '(' parens ')' / ''
+      end
+    end
+
+
+The `parens` expression simply states that a `parens` is a set of parentheses surrounding another `parens` expression or, if that doesn't match, the empty string. If you are uncomfortable with recursion, its time to get comfortable, because it is the basis of language. Here's a tip: Don't try and imagine the parser circling round and round through the same rule. Instead, imagine the rule is *already* defined while you are defining it. If you imagine that `parens` already matches a string of matching parentheses, then its easy to think of `parens` as an open and closing parentheses around another set of matching parentheses, which conveniently, you happen to be defining. You know that `parens` is supposed to represent a string of matched parentheses, so trust in that meaning, even if you haven't fully implemented it yet.
+
+Repetition
+----------
+Any item in a rule may be followed by a '+' or a '*' character, signifying one-or-more and zero-or-more occurrences of that item. Beware though; the match is greedy, and if it matches too many items and causes subsequent items in the sequence to fail, the number matched will never be reconsidered. Here's a simple example of a rule that will never succeed:
+
+    # toogreedy.treetop
+    grammar TooGreedy
+      rule a_s
+      	'a'* 'a'
+      end
+    end
+
+The 'a'* will always eat up any 'a's that follow, and the subsequent 'a' will find none there, so the whole rule will fail. You might need to use lookahead to avoid matching too much. Alternatively, you can use an occurrence range:
+
+    # toogreedy.treetop
+    grammar TooGreedy
+      rule two_to_four_as
+      	'a' 2..4
+      end
+    end
+
+In an occurrence range, you may omit either the minimum count or the maximum count, so that "0.. " works like "*" and "1.. " works like '+'.
+
+Negative Lookahead
+------------------
+
+When you need to ensure that the following item *doesn't* match in some case where it might otherwise, you can use negat!ve lookahead, which is an item preceeded by a ! - here's an example:
+
+    # postcondition.treetop
+    grammar PostCondition
+      rule conditional_sentence
+        ( !conditional_keyword word )+ conditional_keyword [ \t]+ word*
+      end
+
+      rule word
+        ([a-zA-Z]+ [ \t]+) 
+      end
+
+      rule conditional_keyword
+        'if' / 'while' / 'until'
+      end
+    end
+
+Even though the rule `word` would match any of the conditional keywords, the first words of a conditional_sentence must not be conditional_keywords. The negative lookahead prevents that matching, and prevents the repetition from matching too much input. Note that the lookahead may be a grammar rule of any complexity, including one that isn't used elsewhere in your grammar.
+
+Positive lookahead
+------------------
+
+Sometimes you want an item to match, but only if the *following* text would match some pattern. You don't want to consume that following text, but if it's not there, you want this rule to fail. You can append a positive lookahead like this to a rule by appending the lookahead rule preceeded by an & character.
+
+Semantic predicates
+-------------------
+
+Warning: This is an advanced feature. You need to understand the way a packrat parser operates to use it correctly. The result of computing a rule containing a semantic predicate will be memoized, even if the same rule, applied later at the same location in the input, would work differently due to a semantic predicate returning a different value. If you don't understand the previous sentence yet still use this feature, you're on your own, so test carefully!
+
+Sometimes, you need to run external Ruby code to decide whether this syntax rule should continue or should fail. You can do this using either positive or negative semantic predicates. These are Ruby code blocks (lambdas) which are called when the parser reaches that location. For this rule to succeed, the value must be true for a positive predicate (a block like &{ ... }), or false for a negative predicate (a block like !{ ... }).
+
+The block is called with one argument, the array containing the preceding syntax nodes in the current sequence. Within the block, you cannot use node names or labels for the preceding nodes, as the node for the current rule does not yet exist. You must refer to preceding nodes using their position in the sequence.
+
+    grammar Keywords
+      rule sequence_of_reserved_and_nonreserved_words
+      	( reserved / word )*
+      end
+
+      rule reserved
+        word &{ |s| symbol_reserved?(s[0].text_value) }
+      end
+
+      rule word
+        ([a-zA-Z]+ [ \t]+) 
+      end
+    end
+
+One case where it is always safe to use a semantic predicate is to invoke the Ruby debugger, but don't forget to return true so the rule succeeds! Assuming you have required the 'ruby-debug' module somewhere, it looks like this:
+
+      rule problems
+        word &{ |s| debugger; true }
+      end
+
+When the debugger stops here, you can inspect the contents of the SyntaxNode for "word" by looking at s[0], and the stack trace will show how you got there.

data/vendor/bundle/ruby/2.0.0/gems/treetop-1.6.3/Rakefile

@@ -0,0 +1,76 @@
+require 'rubygems'
+require 'bundler'
+Bundler.setup(:default, :development)
+require 'rake'
+require 'jeweler'
+require 'rspec/core/rake_task'
+require File.expand_path("../lib/treetop/version", __FILE__)
+
+Jeweler::Tasks.new do |gem|
+  gem.name = "treetop"
+  gem.version = Treetop::VERSION::STRING
+  gem.author = ["Nathan Sobo", "Clifford Heath"]
+  gem.license = "MIT"
+  gem.email = "cliffordheath@gmail.com"
+  gem.homepage = "https://github.com/cjheath/treetop"
+  gem.platform = Gem::Platform::RUBY
+  gem.summary = "A Ruby-based text parsing and interpretation DSL"
+  gem.description = "A Parsing Expression Grammar (PEG) Parser generator DSL for Ruby"
+  gem.files = [
+      "LICENSE", "README.md", "Rakefile", "treetop.gemspec",
+      "{spec,lib,bin,examples}/**/*",
+      "doc/*"
+    ].map{|p| Dir[p] }.flatten
+  gem.bindir = "bin"
+  gem.executables = ["tt"]
+  gem.require_path = "lib"
+  gem.has_rdoc = false
+end
+Jeweler::RubygemsDotOrgTasks.new
+
+task :default => :spec
+RSpec::Core::RakeTask.new do |t|
+  t.pattern = 'spec/**/*spec.rb'
+  # t.libs << 'spec' # @todo not sure what this did in the original rspec 1.3
+end
+
+task :spec => 'lib/treetop/compiler/metagrammar.treetop'
+file 'lib/treetop/compiler/metagrammar.treetop' do |t|
+  unless $bootstrapped_gen_1_metagrammar
+    load File.expand_path('../lib/treetop/bootstrap_gen_1_metagrammar.rb', __FILE__)
+  end
+
+  Treetop::Compiler::GrammarCompiler.new.compile(METAGRAMMAR_PATH)
+end
+
+task :rebuild do
+  $:.unshift "lib"
+  require './lib/treetop'
+  load File.expand_path('../lib/treetop/compiler/metagrammar.rb', __FILE__)
+  Treetop::Compiler::GrammarCompiler.new.compile('lib/treetop/compiler/metagrammar.treetop')
+end
+
+task :version do
+  puts RUBY_VERSION
+end
+
+desc 'Generate website files'
+task :website_generate do
+  `cd doc; ruby ./site.rb`
+end
+
+desc 'Upload website files'
+task :website_upload do
+  # The website is now done using gh-pages
+  system <<-END
+    git checkout gh-pages
+    cp website/*.html .
+    git add *.html
+    git commit -m"Website update `date`"
+    git push
+    git checkout master
+  END
+end
+
+desc 'Generate and upload website files'
+task :website => [:website_generate, :website_upload]

data/vendor/bundle/ruby/2.0.0/gems/treetop-1.6.3/bin/tt

@@ -0,0 +1,112 @@
+#!/usr/bin/env ruby
+require 'optparse'
+require 'rubygems'
+
+$LOAD_PATH.unshift(File.expand_path(File.dirname(__FILE__) + "/../lib"))
+require 'treetop'
+require 'treetop/version'
+require 'treetop/polyglot'
+
+options = {}
+parser = OptionParser.new do |opts|
+  exts = Treetop::Polyglot::VALID_GRAMMAR_EXT.collect { |i| '.' + i }
+
+  opts.banner = "Treetop Parsing Expression Grammar (PEG) Comand Line Compiler"
+  opts.define_head "Usage: tt [options] grammar_file[#{exts.join('|')}] ..."
+  opts.separator ''
+  opts.separator 'Examples:'
+  opts.separator '  tt foo.tt               # 1 grammar -> 1 parser source'
+  opts.separator '  tt foo bar.treetop      # 2 grammars -> 2 separate parsers'
+  opts.separator '  tt -o alt_name.rb foo   # alternately named output file'
+  opts.separator ''
+  opts.separator ''
+  opts.separator 'NOTE: while treetop grammar files *must* have one of the following'
+  opts.separator 'filename extensions, the extension name is not required when calling'
+  opts.separator 'the compiler with grammar file names.'
+  opts.separator ''
+  opts.separator "  Valid extensions: #{exts.join(', ')}"
+  opts.separator ''
+  opts.separator ''
+  opts.separator 'Options:'
+
+  opts.on('-o', '--output FILENAME', 'Write parser source to FILENAME') do |fn|
+    options[:out_file] = fn
+  end
+
+  opts.on('-f', '--force', 'Overwrite existing output file(s)') do
+    options[:force] = true
+  end
+
+  opts.on_tail('-v', '--version', 'Show Treetop version') do
+    puts "Treetop v#{Treetop::VERSION::STRING}"
+    exit
+  end
+
+  opts.on_tail('-h', '--help', 'Show this help message') do
+    puts opts
+    exit
+  end
+
+end
+file_list = parser.parse!
+
+# check options and arg constraints
+if file_list.empty? || (options[:out_file] && file_list.size > 1)
+  puts parser
+  exit 1
+end
+
+def grammar_exist?(filename)
+  if File.extname(filename).empty?
+    Treetop::Polyglot::VALID_GRAMMAR_EXT.each do |ext|
+      fn_ext = "#{filename}.#{ext}"
+      return true if File.exist?(fn_ext) && !File.zero?(fn_ext)
+    end
+  end
+  File.exist?(filename) && !File.zero?(filename)
+end
+
+def full_grammar_filename(filename)
+  return filename if !File.extname(filename).empty?
+  Treetop::Polyglot::VALID_GRAMMAR_EXT.each do |ext|
+    fn_ext = "#{filename}.#{ext}"
+    return fn_ext if File.exist?(fn_ext) && !File.zero?(fn_ext)
+  end
+end
+
+def protect_output?(filename, forced=false)
+  if !forced and
+      File.exist?(filename) and
+      File.open(filename) { |f| ![(f.gets rescue ''), (f.gets rescue '')].include? Treetop::Compiler::AUTOGENERATED }
+    puts "ERROR: '#{filename}' output already exists; skipping compilation...\n"
+    return true
+  end
+  false
+end
+
+compiler = Treetop::Compiler::GrammarCompiler.new
+
+while !file_list.empty?
+  treetop_file = file_list.shift
+
+  # handle nonexistent and existent grammar files mixed together
+  if !grammar_exist?(treetop_file)
+    puts "ERROR: input grammar file '#{treetop_file}' does not exist; continuing...\n"
+    next
+  end
+
+  # try to compile
+  treetop_file = full_grammar_filename(treetop_file)
+  std_output_file = treetop_file.gsub(Treetop::Polyglot::VALID_GRAMMAR_EXT_REGEXP, '.rb')
+
+  if options[:out_file]
+    # explicit output file name option; never overwrite unless forced
+    next if protect_output?(options[:out_file], options[:force])
+    compiler.compile(treetop_file, options[:out_file])
+  else
+    # compile one input file from input file list option; never overwrite unless forced
+    next if protect_output?(std_output_file, options[:force])
+    compiler.compile(treetop_file)
+  end
+
+end

data/vendor/bundle/ruby/2.0.0/gems/treetop-1.6.3/doc/contributing_and_planned_features.markdown

@@ -0,0 +1,102 @@
+#Google Group
+I've created a <a href="http://groups.google.com/group/treetop-dev">Google Group</a> as a better place to organize discussion and development.
+treetop-dev@google-groups.com
+
+#Contributing
+Visit <a href="http://github.com/nathansobo/treetop/tree/master">the Treetop repository page on GitHub</a> in your browser for more information about checking out the source code.
+
+I like to try Rubinius's policy regarding commit rights. If you submit one patch worth integrating, I'll give you commit rights. We'll see how this goes, but I think it's a good policy.
+
+##Getting Started with the Code
+Treetop compiler is interesting in that it is implemented in itself. Its functionality revolves around `metagrammar.treetop`, which specifies the grammar for Treetop grammars. I took a hybrid approach with regard to definition of methods on syntax nodes in the metagrammar. Methods that are more syntactic in nature, like those that provide access to elements of the syntax tree, are often defined inline, directly in the grammar. More semantic methods are defined in custom node classes.
+
+Iterating on the metagrammar is tricky. The current testing strategy uses the last stable version of Treetop to parse the version under test. Then the version under test is used to parse and functionally test the various pieces of syntax it should recognize and translate to Ruby. As you change `metagrammar.treetop` and its associated node classes, note that the node classes you are changing are also used to support the previous stable version of the metagrammar, so must be kept backward compatible until such time as a new stable version can be produced to replace it.
+
+##Tests
+Most of the compiler's tests are functional in nature. The grammar under test is used to parse and compile piece of sample code. Then I attempt to parse input with the compiled output and test its results.
+
+#What Needs to be Done
+##Small Stuff
+* Improve the `tt` command line tool to allow `.treetop` extensions to be elided in its arguments.
+* Generate and load temp files with `Treetop.load` rather than evaluating strings to improve stack trace readability.
+* Allow `do/end` style blocks as well as curly brace blocks. This was originally omitted because I thought it would be confusing. It probably isn't.
+
+##Big Stuff
+####Transient Expressions
+Currently, every parsing expression instantiates a syntax node. This includes even very simple parsing expressions, like single characters. It is probably unnecessary for every single expression in the parse to correspond to its own syntax node, so much savings could be garnered from a transient declaration that instructs the parser only to attempt a match without instantiating nodes.
+
+###Generate Rule Implementations in C
+Parsing expressions are currently compiled into simple Ruby source code that comprises the body of parsing rules, which are translated into Ruby methods. The generator could produce C instead of Ruby in the body of these method implementations.
+
+###Global Parsing State and Semantic Backtrack Triggering
+Some programming language grammars are not entirely context-free, requiring that global state dictate the behavior of the parser in certain circumstances. Treetop does not currently expose explicit parser control to the grammar writer, and instead automatically constructs the syntax tree for them. A means of semantic parser control compatible with this approach would involve callback methods defined on parsing nodes. Each time a node is successfully parsed it will be given an opportunity to set global state and optionally trigger a parse failure on _extrasyntactic_ grounds. Nodes will probably need to define an additional method that undoes their changes to global state when there is a parse failure and they are backtracked.
+
+Here is a sketch of the potential utility of such mechanisms. Consider the structure of YAML, which uses indentation to indicate block structure.
+
+    level_1:
+      level_2a:
+      level_2b:
+        level_3a:
+      level_2c:    
+
+Imagine a grammar like the following:
+
+    rule yaml_element
+      name ':' block
+      /
+      name ':' value
+    end
+    
+    rule block
+      indent yaml_elements outdent
+    end
+
+    rule yaml_elements
+      yaml_element (samedent yaml_element)*
+    end
+    
+    rule samedent
+      newline spaces {
+        def after_success(parser_state)
+          spaces.length == parser_state.indent_level
+        end
+      }
+    end
+    
+    rule indent
+      newline spaces {
+        def after_success(parser_state)
+          if spaces.length == parser_state.indent_level + 2
+            parser_state.indent_level += 2
+            true
+          else
+            false # fail the parse on extrasyntactic grounds
+          end
+        end
+      
+        def undo_success(parser_state)
+          parser_state.indent_level -= 2
+        end
+      }
+    end
+    
+    rule outdent
+      newline spaces {
+        def after_success(parser_state)
+          if spaces.length == parser_state.indent_level - 2
+            parser_state.indent_level -= 2
+            true
+          else
+            false # fail the parse on extrasyntactic grounds
+          end
+        end
+      
+        def undo_success(parser_state)
+          parser_state.indent_level += 2
+        end
+      }
+    end
+
+In this case a block will be detected only if a change in indentation warrants it. Note that this change in the state of indentation must be undone if a subsequent failure causes this node not to ultimately be incorporated into a successful result.
+
+I am by no means sure that the above sketch is free of problems, or even that this overall strategy is sound, but it seems like a promising path.