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

For the first part, I'd be inclined to say "it's just syntax." Granted, it's _important_ syntax -- we shouldn't force new syntax on programmers unless absolutely necessary -- but _if_ this is actually something a lot of people want to use, would it be hard to make the syntax perlier? Perl5 may not be the best language to express rules, but I get the feeling that Larry's eminent integration of regex backtracking with the rest of the language may change that somewhat.

For the second -- I personally think top-down is more intuitive, but I don't think the "reconfigure the parser" idea is necessarily tied to "the parser" being top-down. Also, the possibility of doing something like this could factor into your definition of "best".

/s

  • Comment on 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: A Macro System for Perl?
by Elian (Parson) on May 06, 2002 at 15:00 UTC
    It's not quite just syntax, though--it's severely restricted syntax. If you want a fast parser, the rules need to be stated in a way that allows the parser rule processor to transform them into a single big glob 'o program. (Generally a state machine, but that's not strictly necessary) The more degrees of freedom you allow in rule specification, the slower and more difficult the parser is to write.

    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.

      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

        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.