Announcing Marpa::R2
What is Marpa?
I am very pleased to announce Marpa::R2 -- "Release 2" of the Marpa parser. For those unfamiliar, the Marpa algorithm is something new in parsing -- it parses anything you can write in BNF and, if your grammar is in one of the classes currently in practical use, it parses it in linear time. Marpa::R2's parse engine is written in optimized C, so that Marpa::R2's speed is competitive with parsers of far less power.
An important feature of the Marpa algorithm is "situational awareness". Marpa knows at every point in the parse exactly how far it has progressed in each rule, and can share this information with the application. The advantages of this go beyond error detection -- Marpa's situational awareness is accurate, graceful and fast enough to be used as a parsing technique in its own right -- Ruby Slippers parsing.
Announcing Marpa::R2
Marpa::R2 2.006000 is alpha, and its interface is not yet frozen. Those who want a stable version of Marpa should prefer Marpa::XS. But Marpa::R2 does pass the same test suite as Marpa::XS, and at least one module has already successfully converted to Marpa::R2.
Marpa::R2 is heavily refactored internally. I expect more benefits of this refactoring to come over the next weeks, in the form of new features. Here are the new features available in this first announced release of Marpa::R2:
- Marpa::R2 is faster than Marpa::XS. The most visible speedup comes from optimizing rules and tokens whose values do not matter, so that the actual speedup varies greatly by application, but it is often 20% or more.
- Marpa::R2 no longer requires Glib. Marpa::R2 now has no non-core Perl dependency.
- Marpa::R2's internal grammar rewrites are now invisible to the user, even when tracing.
Users migrating from Marpa::XS should be aware that, while Marpa::R2's interface is similar to Marpa::XS's, it is not fully compatible. The list of incompatible changes can be found in the Marpa::R2 documentation.
Congratulations on this milestone.
One bit that slightly itches me from the start: having to explicitly say $grammar->precompute. Can't Marpa just perform this on behalf of the user when it needs to? It's just one more thing to hide from the user to make things simpler (being one of the users, I'd say there are still a few :).
@Steven: Some early versions of Marpa did this. However, a lot of problems with the grammar are caught at precomputation time, so the error reporting actually can make the interface seem more complex rather than less -- it certainly lengthens the documentation. Also, the logic is clearer when grammar changes are done by grammar mutators rather than recognizer constructors. The more I worked on Marpa, the more I felt the need to make the objects simpler, even if less smart about "doing what you mean".
Is it time to go full circle and auto-precompute grammars as needed? I don't know. But as we speak, a number of people are laboring to take me out of the interface game, a goal very near to my heart. If there is one right way to handle this issue, I hope it will be found by someone else.
Congratulations on the release, and also, a hearty "well done!" for removing the Glib dependency! Nothing against Glib, but being able to cpanm Marpa::R2 should help your adoption rate.
Cheers!
@Joel: Thanks! Actually cpanm ran fine on systems that already have GNU's glib library installed, whiich is the majority of POSIX systems. And for those that didn't, installing GNU's glib was easy to do. 'cpanm' is how I install the packages.
I removed the Glib dependency primarily because of two constituencies.
1.) Adam Kennedy. We talked about a Windows port and, while in theory Glib runs on Windows, in practice the combination seems to be a very dicey thing.
2.) cpantesters. Installing GNU's glib when missing was easy one extra step, and smokers don't do extra steps. They would just return "UNKNOWN".
Also, I definitely agree. No knock on Glib and the generous follks who maintain both the Perl module and the GNU package. It was a major help during Marpa's evolution.