Re: recdescent 2.0 and Perl 6

sorry about the late response

Damian Conway wrote:
> Aamer Akhter wrote:
> 
>> ok, this may be a really dumb question, it's not meant to be a 
>> political one, just to help me plan.
>>
>> We're starting a project that includes a parser that would convert a 
>> huge swath of multi-device output (output of explicit commands) to an 
>> XML tokenized form. More than likely, perl would run in an embedded 
>> from from tcl (this is the reality we're dealing with-- but we're 
>> hoping parrot can save us ;-))
>>
>> Some of this output is potentially very large (although repeating). 
>> I've written parse::recdescent grammars for some of this output in the 
>> past but speed was the biggest issue. Has anybody done speed 
>> comparisons between Perl6::Rules and prd?
>>
>> I realize that perl6 is still evolving, but at least we can change our 
>> copy of Perl6::Rules on our schedule, if the benefits outweigh the 
>> shifting sands... 
> 
> 
> Do NOT use Perl6::Rules for production code. The module is only at 
> release 0.03, which is *far* too early to rely on it.
> 
> Apart from the fact that the rule syntax and matching semantics for Perl 
> 6 are still changing occasionally, the module still has a raft of known 
> bugs and limitations. Many of these are in fact bugs and limitations in 
> the underlying Perl 5 regex engine (which has apparently never been 
> pushed quite as far as I'm pushing it now). Some of the most serious 
> underlying bugs will probably not be fixed in the foreseeable future -- 
> perhaps not before perl 5.10 is released, maybe not even then.
> 
> All of which means Perl6::Rules is NOT production-ready, and unlikely to 
> be production-ready in any reasonable time-frame.


Damian, thank-you for writing and supporting prd. Your point about the 
evolving/alpha state of Perl6::Rules is taken. I am progressing with the eval of 
  prd for our uses.

Thanks for the <autotree> command option. :-)

> I am currently a little preoccupied with the upcoming conference season, 
> and with working on Exegesis 12. At the same time I *am* reassessing the 
> Parse::RecDescent and Perl6::Rules modules to determine how best to 
> proceed.
> Options include:
> 
>     * Working (with P5P) to resolve the major bugs in Perl6::Rules
> 
>     * Implementing an entirely new and separate regex matching engine
>       to sit under Perl6::Rules
> 
>     * Proceeding with my original plans to improve Parse::RecDescent
>           performance
> 
>     * Proceeding with my later plans to create a new, faster
>       Parse::FastDescent module
> 
>     * Giving up and moving to Tibet ;-)
> 
> However, I will not be making any decisions on this until at least 
> September,
> when I return from my forthcoming speaking tour.
> 
> In the meantime my best advice remains the same: if you can't live with 
> the performance of Parse::RecDescent, and can't tweak your grammar to 
> improve that performance sufficiently, consider using Parse::Yapp or 
> perl-byacc instead.

Those are excellent modules, and we may eventually have to use them or plain old 
  regex in some extreme cases. The hope is that we can create a frontend that is 
agnostic to which particualr parser is being used. The front end will use some 
kind of parser/grammar registry to match parsers to the atomic value the user is 
really looking for.

> Sorry not to be of more help,
> 
> Damian