On Wed, 12 May 2004, Larry Wall wrote: > In fact, I'd go so far as to say that it's almost impossible to do > recursive descent when you allow for defining new operator precedence > levels on the fly as Perl 6 does. > > : Operator precedence can be done in > : a recdescent grammar straightforwardly enough. It's a bit longwinded, > : but doable. > > Yes, of course, it *can* be done that way. The point is you don't > *want* to do that part in recursive descent,
I see a terminology issue looming here. Er, what is recdescent? The dragon book and Parse::RecDescent do not seem to use the same defn. According to aho/ullman "A parser that uses a set of recursive procedures to recognize its input with no backtracking is called a recursive descent parser". (p 180). Parse::RecDescent does not shy away from backtracking, and in Aho/Ullman's eyes it would be a top-down parser, but not recdescent. As usual, I may have missed something. I am not sure which of the two you mean, but I feel it is the Parse::RecDescent sense because it is powerful and easier for users (and does not require recomputing the parsing table), but it is also (much?) slower. Or, of course, you may mean both. When a program uses a lot of evals then it may be worthwhile when compiling the program to calculate the parse-tables and other no-backtracking book-keeping so that the eval's happen faster at runtime. > Larry --abhijit
