in reply to Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: A Macro System for Perl?
in thread A Macro System for Perl?

The problem with top-down parsing is that it's slow. The more states and rules, the slower it is. Perl's grammar would take ages to process by a top-down parser.
Speaking as someone currently wrestling with Inline::CPP, "amen". In the interest of finding out how it was getting lost in my C++, I turned on tracing, and was presented with the spoor of something like two minutes of backtracking fury. I'm not about to try and re-implement it in Parse::YAPP, though...

/s

  • Comment on Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: A Macro System for Perl?

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: A Macro System for Perl?
by Elian (Parson) on May 07, 2002 at 14:12 UTC
    Parse::RecDescent matches well with the way a lot of people think about parsing, which is one of the reasons it's so popular, I think. (That and the fact that Damian writes darned good software) Unfortunately recursive descent parsing is just darned slow in general, so we can't use it for Parrot's parser.

    Parrot's parser will likely be more like the classic parsing tools. They're classic because they work and work quickly, and this is one of the places where programmer convenience will get sacrificed for speed.

      Okay, I've done the YACC thing before, and while it's not quite as intuitive, it's not so bad. Furthermore, if most of the slowness of RecDescent is from its being top-down, not from its being full-featured and in-perl, then recompiling the parser after each syntax block should be considered possible. (yacc perly.y; gcc -c y.tab.c) takes about 1 second on my laptop, and since this feature will be more useful in major scripts than one-liners, since we can probably cache standard-library transformations, etc., performance problems don't put this sort of thing out of reach.

      Of course, I'm not volunteering to write the code here...

      /s