As a Parslet user (not developer of Parslet), I find the Parslet
approach to be a lot easier to debug and work with than the treetop code
generation approach. I generally don't like generated code though.
I'm not sure I'd describe the Parlset approach as "keeping it in memory"
exactly. Rather, Parslet is just ruby classes that parse, configured by
a grammar. Is the way I think of it at least.
This leads to a lot more flexibility working with Parslet, everything is
just an ordinary ruby object that you can interact with in ordinary
ways, including parsing on individual rules as 'root' (very useful for
development), adding rules with methods or module inclusion, etc. The
Parslet approach seems like a lot less 'magic' to me working on a
parser, there's less indirection going on.
So to me as a user of Parslet, that's the main advantage; I find the
Parslet approach easier to work with than the treetop approach.
Apparently some benchmarks say Parslet is also faster than treetop; I
couldn't say if this is related to the "code generation" vs "not"
approaches or not.
On 4/26/2011 10:34 AM, Dotan N. wrote:
Thanks for the answers guys!
I think the fact that Parslet can understand Treetop grammar is
excellent (which is my first question).
it may have been a language barrier - but i wasn't looking for a way
to convert Parslet to Treetop :)
what i was intending to ask is that i was wondering about what are the
benefit of generating code (treetop) vs keeping it in memory (parslet)
regarding the code for the parser - unfortunately i can't put it out,
but it is a parallel of a log / machine output parser - very simple.
I'll try to abstract out the details and publish something about it
and benchmarks towards weekend
thanks again! :)
On Tue, Apr 26, 2011 at 4:56 PM, Kaspar Schiess <[email protected]
<mailto:[email protected]>> wrote:
Hi Dotan,
Glad to hear that parslet is working fine for you!
> Secondly, is there _any_ way to use treetop grammars with
parslet? what I
> turned to do was a mechanic search + replace of my treetop
grammar plus
> minor hand tweaks. immediately I was wondering about that.
>
> When I finished, I realized I had two versions of the parser
written with
> both treetop and parslet. As a typical engineer I ran a quick
benchmark --
> and parslet (1.2.0) was faster by a considerable margin (perhaps
i'll post
> the results further down the week).
I would love to see the benchmark and the results. Here are mine ;)
http://blog.absurd.li/2011/02/02/parslet_and_its_friends.html
(Somewhat
old, but still valid. Misleading X axis, all my fault)
Like Jason mentioned, Parslet has the experimental foreign expression
parse feature; one of the things that didn't convince me completely
after I had built it. It's still in there, although somewhat
unfinished;
have a look at expression_spec.rb and the 'exp' method. For example:
exp("'a' 'b')
will be equal to
str('a') >> str('b')
I mostly use it to round-trip test the #inspect method of all parslet
atoms. It doesn't do a lot of things Treetop grammars do, like
predicates and .. of course action blocks. But its a start.
Parslet exports (on the other hand) neatly to citrus and treetop -
although it beats me why you would ever want to leave us, we're so
friendly ;)
Likewise, I think it would probably be easier to extend Treetop with
parslet output than it is to built another treetop parser. And
there is
the matter of the small incompatibilities/ the opinionated bits about
parslet that don't fit Treetop exactly.
So no, no direct conversion now, and probably never. Its just too easy
to rebuild parsers; plus - most of the treetop code I've seen isn't
tested, something I heavily recommend.
best regards,
kaspar
