From: Clifford Heath Date: 2011-02-17T06:50:37+09:00 Subject: Re: Treetop - parsing to nil result On 02/17/11 08:13, Christopher Rose wrote: > I parse a smallish, syntactically correct example input and get a nil > result, like this; A nil result means your parser failed to parse all the input. Have you tried with minimal inputs? Have you tested the parser rules from the bottom up, or only started from the head rule? It's important to develop these grammars incrementally. > irb(main):188:0> resA = pA.parse(exA) > => nil > irb(main):189:0> resA.failure_reason > NoMethodError: undefined method `failure_reason' for nil:NilClass > from (irb):189 failure_reason is a method on the parser object, not on the result. > Can someone please suggest some other avenues for debugging this? By default, Treetop starts with the first rule in your grammar, but you can direct it to start elsewhere by passing the :root option to the parse method. Also, a common trap is that the grammar must consume all the input, unless you pass :consume_all_input => false. So when you use :root, either feed it a fragment of input that matches the root rule exactly, or set consume_all_input so that won't matter. Another trap that strikes people coming from other parser generators is that Treetop has no implicit white-space skipping. Your grammar must account for every byte of input. Another hardcore debugging trick is to use a semantic predicate to insert a call to the debugger. After requiring 'ruby-debug', insert this somewhere: &{|s| debugger; true } s will be set to an array of the SyntaxNodes that have been parsed so far in this rule (or sub-rule, if you used parentheses). You can look at the variables "input" and "offset", or more usefully, input[offset, 50]. Of course, you don't have to use a debugger, you can just print something. Just remember to return true, or that rule fails. If you can't make progress, contact us on the Treetop developers ML at and post the problem parts of your grammar somewhere. Clifford Heath, Treetop maintainer.