How do I find out exactly what is wrong?
winkerbean
I am receiving this diagnostic:
`_nt_A': uninitialized constant B::C (NameError)
where 'A' is defined with:
grammar D
rule A
!E . <C>
end
end
in a *.treetop file and 'C' is defined with:
module F
class C < Treetop::Runtime::SyntaxNode
end
end
in a *.rb file. Can Anyone point Me in the direction of information
which would help Me determine exactly what the problem is? I am using
Treetop #1.4.9 and Ruby # 1.9.2p136.
Thanks!
markus
Try changing it to a fully qualified reference:
> grammar D
> rule A
> !E . <C>
!E . <F::C>
> end
> end
or import F above/before the grammar.
-- MarkusQ
Frank
I found the problem. If I change 'F' to 'D', I can avoid this
problem. Now, I have a new problem. I am getting "in `extend': wrong
argument type Class (expected Module) (TypeError)" for a rule defined
like so:
rule A
B <C>
end
where C is defined to inherit from Treetop::Runtime::SyntaxNode.
According to the stack trace from the error output, I see this occurs
in "_nt_A". If I convert the TT file to Ruby, by means of the tt
application, and step thru the debugger, I see the problem occurs in
_nt_A where:
r0 = _nt_B
r0.extend(C)
appears.
Any suggestions on how to proceed?
> --
> You received this message because you are subscribed to the Google Groups "Treetop Development" group.
> To post to this group, send email to treet...@googlegroups.com.
> To unsubscribe from this group, send email to treetop-dev...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/treetop-dev?hl=en.
>
>
markus
> Hi, MarkusQ.
> I found the problem. If I change 'F' to 'D', I can avoid this
> problem. Now, I have a new problem. I am getting "in `extend': wrong
> argument type Class (expected Module) (TypeError)" for a rule defined
> like so:
> rule A
> B <C>
> end
> where C is defined to inherit from Treetop::Runtime::SyntaxNode.
> According to the stack trace from the error output, I see this occurs
> in "_nt_A". If I convert the TT file to Ruby, by means of the tt
> application, and step thru the debugger, I see the problem occurs in
> _nt_A where:
> r0 = _nt_B
> r0.extend(C)
> appears.
> Any suggestions on how to proceed?
I'm not clear on what you are trying to accomplish, but can you just
make C a module (that wouldn't inherit from anything but which would be
used to extend a SyntaxNode, for similar effect)?
If not, and if the reason is that you are trying to make the AST
produced by Treetop "represent" the results by comprising objects of
specific classes, my personal advice would be...turn back. That story
never ends well, and at best you will wind up fighting the tools all the
way to produce something brittle and hard to maintain. Instead, have
the AST produce the results you want directly, without trying to make it
be something it isn't.
-- MarkusQ
Clifford Heath
Markus is right; let the syntax tree be a syntax tree, don't try to
use it as your semantic model.
However, to explain your original question, when you have a
rule (or an alternate) consisting of exactly one non-terminal,
Treetop uses the object that was created for that non-terminal,
instead of making a new sequence of one element. Consequently
your "B" represents an existing object, not a new one, and you
can't extend a class into that object. If it was a terminal, or if you
had another item in the rule, no problem because that requires
a new node. Sometimes I use an empty string to match nothing,
but make a single term into a sequence, in a situation like this:
rule A
( B "" / C D ) <E>
end
If I didn't add the empty string, the B path would fail.
Clifford Heath.
Frank
That was not the impression I got from
http://thingsaaronmade.com/blog/a-quick-intro-to-writing-a-parser-using-treetop.html
which explicitly uses class names.
Frank
On 19 July 2011 22:30, Clifford Heath <cliffor...@gmail.com> wrote:
> Frank,
>
> Markus is right; let the syntax tree be a syntax tree, don't try to
> use it as your semantic model.
Ditto what I said to Markus.
> However, to explain your original question, when you have a
> rule (or an alternate) consisting of exactly one non-terminal,
> Treetop uses the object that was created for that non-terminal,
> instead of making a new sequence of one element. Consequently
> your "B" represents an existing object, not a new one, and you
That makes more sense.
> can't extend a class into that object. If it was a terminal, or if you
> had another item in the rule, no problem because that requires
> a new node. Sometimes I use an empty string to match nothing,
> but make a single term into a sequence, in a situation like this:
>
> rule A
> ( B "" / C D ) <E>
> end
>
> If I didn't add the empty string, the B path would fail.
I think You lost Me there. But it also might be either the fact it's
late here or My lack of experience with Treetop. On that note, I know
TT has a reputations for being skimpy on documentation but it really
seems more sparse in explanation than imagined. Is there a /thorough/
tutorial on using Treetop?
Clifford Heath
>> rule A
>> ( B "" / C D ) <E>
>> end
>>
>> If I didn't add the empty string, the B path would fail.
>
> I think You lost Me there.
Actually I think I lost myself :). When I use an empty string, it's not
so I can use a module, but to regularise access (e.g. elements[0]).
In my defence, I'm at home, too sick to work today.
> On that note, I know
> TT has a reputations for being skimpy on documentation but it really
> seems more sparse in explanation than imagined. Is there a /thorough/
> tutorial on using Treetop?
Only what you see, unfortunately, which is what Nathan has written when
the project was orphaned, as updated from time to time mostly by me.
Pull requests are welcome :).
Clifford Heath.
markus
> So, wait, in between the '<>' I cannot/should-not place a class name?
You can, sometimes, but IHMO you shouldn't.
> That was not the impression I got from
> http://thingsaaronmade.com/blog/a-quick-intro-to-writing-a-parser-using-treetop.html
> which explicitly uses class names.
It does work sometimes, but you have to be careful. The rule used to be
"A module for a singleton node, a class for a compound node" but this
required knowing what type of node would be produced, which has gotten
increasingly tricky. That's why I submitted the patch bach around
1.2.5 (https://github.com/MarkusQ/treetop-patch-proposals) which makes
it always accept modules.
So now I always / only use modules.
It always works, and it's easy to remember. :)
-- M
Frank
>
> Pull requests are welcome :).
>
> Clifford Heath.
If I can ever understand TT enough to make some, You just might get some. ;-)
Frank
showing how to use modules? Any tutorials, perhaps?
markus
> Ah, well, can you point in Me in the direction of documentation
> showing how to use modules? Any tutorials, perhaps?
Short form: they are like classes except they don't have super classes
and you can't instantiate them. They are modifiers that you can attach
to a class the way adjectives can be attached to a noun.
For more, check any book on ruby, ask google, or take a look at these:
http://www.rubyfleebie.com/an-introduction-to-modules-part-1/
http://www.rubyist.net/~slagell/ruby/modules.html
-- MarkusQ
Frank
translator which requires I be able to walk an AST, which is why I was
looking to utilize the class approach. Thanks just the same.
Clifford Heath
> Hmm, I'm not really seeing how this helps. See, I am writing a
> translator which requires I be able to walk an AST, which is why I was
> looking to utilize the class approach. Thanks just the same.
You can still walk the AST (though it's preferable for the AST to walk
itself).
The difference is that all nodes will be SyntaxNode (not a subclass
which
you instantiated), but with any additional methods from mix-in modules
added.
This is much preferable to using your own classes. For one thing, in the
case where Treetop re-uses a node instead of creating a unary sequence,
you can mix in multiple modules. The modules can even inherit the
behaviour
of earlier modules by calling super.
If you want to avoid pain, add methods to each node to descend the tree
and build your output by recursive descent. Don't write an external
walker
method that traverses the tree.
Clifford Heath.