in reply to On modules

TheDamian once explained to me why my attempt to parse all 22 levels of Perl's precedence (at that time) with a recursive descent parser was a really bad idea. I don't fully remember why at this point, but you're obviously stumbling on the same situation. Like everything else, Recursive Descent has plusses and minuses.

I think your meditation is misnamed then. The problem is not using a module: the problem is using the wrong module simply because you're familiar with it. For example, Parse::Yapp makes a different kind of parser (LALR or something like that) that might have solved your issues lickity split.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Replies are listed 'Best First'.
Re^2: On modules
by samizdat (Vicar) on Aug 18, 2005 at 17:16 UTC
    That could be true as well, merlyn. Recursive descent (the methodology) is the right way to do this sort of thing, but what TheDamian's module does isn't exactly classic RD. It is hard to do this in P::RD where it might be better done in a YACC-style parser because of the left recursion issue.

    I was as frustrated with using the module itself as I was with the slowness of the program. Part of the reason I rewrote it was so that I could build my own trace functions and examine my own variables and stacks. I felt that understanding TheDamian's code would have taken me as long as the approach I took, and might not have given me the same results. That's the main reason I focused on the use of modules, and it's a broader concern than just with P::RD. As you say, any module and / or approach has its plusses and minuses and these must be evaluated for each problem one approaches.
[reply]
      Recursive descent (the methodology) is the right way to do this sort of thing
      No, this is apparently the problem. RD is great for some things, but not for this. There's a reason that gcc is not RD, but LALR. Again, I'm a bear of very little brane about this, but when TheDamian explained it to me, it made sense at the time. It doesn't matter how fast you speed it up: something with 22 levels of precedence should be parsed with LALR (if it can), not RD.

      -- Randal L. Schwartz, Perl hacker
      Be sure to read my standard disclaimer if this is a reply.

[reply]
        What I appear to have implemented is a homebrew 'Packrat Parser', which is RD with a modifiable context stack. I think that the recursive nature of my problem, in which any given non-operator element might itself be another whole expression, function, or if-then-else statement, leads me to some form of cascading procedural solution.

        I'll go back and reread my Pigeon (lex & yacc) book and see if I can find some Aho to see if I can grok this more deeply. The whole subject is worth understanding thoroughly.

        Thanks for your comments, merlyn!
[reply]

In Section Meditations