Treetop - parsing to nil result

[Christopher Rose]

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 -

 

[Ryan Davis]

irb(main):178:0> pA =3D VHDLParser.new
=3D> #<VHDLParser:0x8b5bc6c @consume_all_input=3Dtrue>
=20
irb(main):188:0> resA =3D pA.parse(exA)
=3D> nil
=20
irb(main):189:0> resA.failure_reason
NoMethodError: undefined method `failure_reason' for nil:NilClass
from (irb):189
from :0
=20
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.
=20
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 =3D ArithmeticParser.new
result =3D parser.parse('4+=3D3')

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

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

 

[Clifford Heath]

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 Heath, Treetop maintainer.