Treetop - parsing to nil result

Ruby
1

Hello All,
please forgive a very novice question on what may be an arcane topic. I
have a Treetop grammar defined, the ‘tt’ compiler seems to digest it
without complaint, I get no errors when I create a new parser instance.
I parse a smallish, syntactically correct example input and get a nil
result, like this;

irb(main):178:0> pA = VHDLParser.new
=> #<VHDLParser:0x8b5bc6c @consume_all_input=true>

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
from :0

The description at treetop.rubyforge.org seems to suggest that if the
parse fails, the methods failure_reason, failure_line, and
failure_column would exist in such a way as to point to and describe the
reason for failure.

Can someone please suggest some other avenues for debugging this?

Thanks -

2

On Feb 16, 2011, at 13:13 , Christopher R. wrote:

The description at treetop.rubyforge.org seems to suggest that if the
parse fails, the methods failure_reason, failure_line, and
failure_column would exist in such a way as to point to and describe the
reason for failure.

Can someone please suggest some other avenues for debugging this?

nil is nil… so once you get it there is no reason to call unrelated
methods on it. The doco suggests asking the parser object, not the
result object:

parser = ArithmeticParser.new
result = parser.parse(‘4+=3’)

if !result
puts parser.failure_reason
puts parser.failure_line
puts parser.failure_column
end

via http://treetop.rubyforge.org/using_in_ruby.html

3

On 02/17/11 08:13, Christopher R. 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
http://groups.google.com/group/treetop-dev/ and post the problem parts
of your grammar somewhere.

Clifford H., Treetop maintainer.

4

Clifford H. wrote in post #982088:

It’s important to develop these grammars incrementally.
Clifford H., Treetop maintainer.

Thanks for the debugging hints - just the suggestions I was looking for.

My first Treetop attempt was parsing “W083.29.44.999”.

Unfortuantely, the first rule I had whipped out in my excitement at
getting started was:
rule digit
[1-9]
end

Luckily, following Clifford’s advice, my first Test::Unit test was that
ancient rule all the way down in the grammar file:

def test__digit__0_parses
result = @parser.parse(“0”, :root=> “digit”, :consume_all_input =>
true)
assert_not_nil(result)
end

Oh well, on to the less lucky bugs! :slight_smile: