in reply to Yacc is dead

Let's see. The choice is between using:

What benefit is there for the latter?

That it can only be written and maintained in obscure, compiled languages by people with an MS in theoretical BS perhaps?


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^2: Yacc is dead
by casiano (Pilgrim) on Dec 08, 2010 at 23:00 UTC
    First. As Russ points out the critique of the practice of parsing context free languages with regular expressions is scathing. I add that is unfair.

    The problem is in the people in the use of cut and paste imitation and copying “magic” regular expressions without fully understanding them. You must understand what you are doing.

    In fact I am not so sure about the goodness of the algorithm proposed in "The Yacc is dead" paper.

    According to Russ analysis, the proposed algorithm - due to backtracking - fails to guarantee the required efficiency. He said:

    'Instead of ending the supposed problem of cargo cult parsing, the paper ends up being a prime example of what Richard Feynman called “cargo cult science” ... in which a successful line of research is imitated but without some key aspect that made the original succeed'

    There is nothing bad in using regular expressions to parse context free languages. I do it. My concern is about the lack of some important parsing algorithms in CPAN, like GLR.

    I am sure also that yacc is not dead (yet). "The asteroid to kill this dinosaur is still in orbit.”

      I admit it's a long time ago I had to parse something as "complex" as a context-free language. But I've done quite a lot of regular expression mojo since.

      Even with 5.10 regular expressions, I would not use regular expressions to parse something. I'd use regular expressions to tokenize the stream, but I'd use some kind of state machine for the parsing. I do consider Parse::RecDescent to implement a state machine, with hooks for callbacks, that uses regular expressions to tokenize. (Of course, regular expressions themselves are state machines...)

      Of course, I may change my mind halfway the project....