From: Nadim Khemir [mailto:[EMAIL PROTECTED]] > > I really think that Inline will not get used to its full > potential (that is writing inline code, generating modules > that can be installed is fine) before this problem get > fixed. I can think of cases where I want to generate > C code at run time and waiting for compilation that spends > 99% in the parser is just overkill.
Well runtime compilation with Win32 and cl.exe is painfully slow for reasons that have nothing to do with parsing. Maybe Sam Tregar could share some tips on do's and don't of speed considerations when writing a grammar. Lessons he's learned rewriting his grammar for HTML::Template::Expr. I noticed this (http://search.cpan.org/doc/TBONE/Parse-RecDescent-FAQ-2.22/FAQ.tt) FAQ and thought you all might be interested. It has nice section called "OPTIMIZING YOUR GRAMMARS", and lots of other tips. > One simple solution, rather inelegant compare with using > Parse::Recdescent, would be to write the parser in Yacc. > But let wait and see what Parse::Recdescent 2.0 brings for > Christmas. I wonder how hard it would be to make Inline's parser pluggable... Then again, I'm happy with Parse::RecDescent, so it's not worth my pain finding out. > From tail of the tutorial documentation for > Parse::RecDescent... Damian writes: > > > version 2.00 (which should be in the CPAN for Christmas) > > will feature a considerable speed boost. Actually, the tutorial is supposedly a reprint from the Issue #12, Winter 1998!!! -Though it was added to the CPAN package in March 2000, so maybe he did mean Xmas 2000. I do know that it is a goal of Perl6 to parse perl in perl, and I know Damian is several others are working to make this possible. I'm not sure whether what results will be a new version of Parse::???Descent, or something fundamentally different. But it will surely be faster and more flexible than Parse::RecDescent. And if it can parse Perl... it'll be able to parse most everything ;)
